summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorLorry <lorry@roadtrain.codethink.co.uk>2012-08-22 15:47:16 +0100
committerLorry <lorry@roadtrain.codethink.co.uk>2012-08-22 15:47:16 +0100
commit25335618bf8755ce6b116ee14f47f5a1f2c821e9 (patch)
treed889d7ab3f9f985d0c54c534cb8052bd2e6d7163 /doc
downloadbzr-tarball-25335618bf8755ce6b116ee14f47f5a1f2c821e9.tar.gz
Tarball conversion
Diffstat (limited to 'doc')
-rw-r--r--doc/Bazaar-Logo-For-Manuals.pngbin0 -> 3880 bytes
-rw-r--r--doc/default.css164
-rw-r--r--doc/developers/HACKING.txt664
-rw-r--r--doc/developers/_static/bzr icon 16.pngbin0 -> 809 bytes
-rw-r--r--doc/developers/_static/bzr-doc.css4
-rw-r--r--doc/developers/_static/bzr.icobin0 -> 13094 bytes
-rw-r--r--doc/developers/_templates/layout.html13
-rw-r--r--doc/developers/add.txt34
-rw-r--r--doc/developers/annotate.txt28
-rw-r--r--doc/developers/api-versioning.txt133
-rw-r--r--doc/developers/apport.txt87
-rw-r--r--doc/developers/authentication-ring.txt418
-rw-r--r--doc/developers/btree_index_prefetch.txt294
-rw-r--r--doc/developers/bug-handling.txt330
-rw-r--r--doc/developers/bundle-creation.txt37
-rw-r--r--doc/developers/bundle-format4.txt272
-rw-r--r--doc/developers/bundles.txt85
-rw-r--r--doc/developers/case-insensitive-file-systems.txt97
-rw-r--r--doc/developers/check.txt63
-rw-r--r--doc/developers/code-review.txt104
-rw-r--r--doc/developers/code-style.txt518
-rw-r--r--doc/developers/colocated-branches.txt129
-rw-r--r--doc/developers/commit.txt635
-rw-r--r--doc/developers/conf.py81
-rw-r--r--doc/developers/configuration.txt366
-rw-r--r--doc/developers/container-format.txt248
-rw-r--r--doc/developers/content-filtering.txt147
-rw-r--r--doc/developers/contribution-quickstart.txt134
-rw-r--r--doc/developers/cycle.txt427
-rw-r--r--doc/developers/development-repo.txt277
-rw-r--r--doc/developers/diff.txt110
-rw-r--r--doc/developers/directory-fingerprints.txt359
-rw-r--r--doc/developers/dirstate.txt60
-rw-r--r--doc/developers/documenting-changes.txt100
-rw-r--r--doc/developers/ec2.txt208
-rw-r--r--doc/developers/feature-flags.txt150
-rw-r--r--doc/developers/fetch.txt171
-rw-r--r--doc/developers/gc.txt26
-rw-r--r--doc/developers/groupcompress-design.txt115
-rw-r--r--doc/developers/implementation-notes.txt28
-rw-r--r--doc/developers/improved_chk_index.txt474
-rw-r--r--doc/developers/incremental-push-pull.txt279
-rw-r--r--doc/developers/index-plain.txt158
-rw-r--r--doc/developers/index.txt94
-rw-r--r--doc/developers/indices.txt111
-rw-r--r--doc/developers/initial-push-pull.txt69
-rw-r--r--doc/developers/integration.txt362
-rw-r--r--doc/developers/inventory.txt613
-rw-r--r--doc/developers/last-modified.txt176
-rw-r--r--doc/developers/lca-merge.txt175
-rw-r--r--doc/developers/lca_tree_merging.txt126
-rw-r--r--doc/developers/merge-scaling.txt35
-rw-r--r--doc/developers/miscellaneous-notes.txt20
-rw-r--r--doc/developers/missing.txt27
-rw-r--r--doc/developers/nested-trees.txt1023
-rw-r--r--doc/developers/network-protocol.txt468
-rw-r--r--doc/developers/new-config-rationale.txt790
-rw-r--r--doc/developers/overview.txt431
-rw-r--r--doc/developers/packrepo.txt287
-rw-r--r--doc/developers/performance-roadmap-rationale.txt116
-rw-r--r--doc/developers/performance-roadmap.txt60
-rw-r--r--doc/developers/performance-use-case-analysis.txt113
-rw-r--r--doc/developers/performance.dot137
-rw-r--r--doc/developers/planned-change-integration.txt143
-rw-r--r--doc/developers/planned-performance-changes.txt167
-rw-r--r--doc/developers/plans.txt11
-rw-r--r--doc/developers/plugin-api.txt262
-rw-r--r--doc/developers/ppa.txt367
-rw-r--r--doc/developers/principles.txt62
-rw-r--r--doc/developers/profiling.txt64
-rw-r--r--doc/developers/releasing.txt752
-rw-r--r--doc/developers/repository-stream.txt200
-rw-r--r--doc/developers/repository.txt354
-rw-r--r--doc/developers/revert.txt26
-rw-r--r--doc/developers/revision-properties.txt46
-rw-r--r--doc/developers/specifications.txt77
-rw-r--r--doc/developers/status.txt100
-rw-r--r--doc/developers/testing.txt1124
-rw-r--r--doc/developers/tortoise-strategy.txt463
-rw-r--r--doc/developers/transports.txt108
-rw-r--r--doc/developers/ui.txt235
-rw-r--r--doc/developers/uncommit.txt21
-rw-r--r--doc/developers/update.txt69
-rw-r--r--doc/developers/win32_build_setup.txt215
-rw-r--r--doc/developers/xdg_config_spec.txt27
-rw-r--r--doc/en/Makefile121
-rw-r--r--doc/en/_static/bzr icon 16.pngbin0 -> 809 bytes
-rw-r--r--doc/en/_static/bzr.icobin0 -> 13094 bytes
-rw-r--r--doc/en/_static/en/Makefile23
-rw-r--r--doc/en/_static/en/bzr-en-quick-reference.pdfbin0 -> 48840 bytes
-rw-r--r--doc/en/_static/en/bzr-en-quick-reference.pngbin0 -> 708125 bytes
-rw-r--r--doc/en/_static/en/bzr-en-quick-reference.svg1598
-rw-r--r--doc/en/_templates/index.html71
-rw-r--r--doc/en/_templates/layout.html8
-rw-r--r--doc/en/admin-guide/advanced.txt164
-rw-r--r--doc/en/admin-guide/backup.txt204
-rw-r--r--doc/en/admin-guide/code-browsing.txt128
-rw-r--r--doc/en/admin-guide/hooks-plugins.txt310
-rw-r--r--doc/en/admin-guide/index-plain.txt24
-rw-r--r--doc/en/admin-guide/index.txt26
-rw-r--r--doc/en/admin-guide/integration.txt14
-rw-r--r--doc/en/admin-guide/introduction.txt55
-rw-r--r--doc/en/admin-guide/licence.txt7
-rw-r--r--doc/en/admin-guide/migration.txt73
-rw-r--r--doc/en/admin-guide/other-setups.txt60
-rw-r--r--doc/en/admin-guide/security.txt116
-rw-r--r--doc/en/admin-guide/simple-setups.txt142
-rw-r--r--doc/en/admin-guide/upgrade.txt77
-rw-r--r--doc/en/conf.py106
-rw-r--r--doc/en/index.txt20
-rw-r--r--doc/en/make.bat112
-rw-r--r--doc/en/mini-tutorial/index.txt256
-rw-r--r--doc/en/quick-reference/index.txt6
-rw-r--r--doc/en/release-notes/bzr-0.1.txt753
-rw-r--r--doc/en/release-notes/bzr-0.10.txt90
-rw-r--r--doc/en/release-notes/bzr-0.11.txt226
-rw-r--r--doc/en/release-notes/bzr-0.12.txt146
-rw-r--r--doc/en/release-notes/bzr-0.13.txt145
-rw-r--r--doc/en/release-notes/bzr-0.14.txt168
-rw-r--r--doc/en/release-notes/bzr-0.15.txt391
-rw-r--r--doc/en/release-notes/bzr-0.16.txt379
-rw-r--r--doc/en/release-notes/bzr-0.17.txt129
-rw-r--r--doc/en/release-notes/bzr-0.18.txt274
-rw-r--r--doc/en/release-notes/bzr-0.6.txt227
-rw-r--r--doc/en/release-notes/bzr-0.7.txt308
-rw-r--r--doc/en/release-notes/bzr-0.8.txt340
-rw-r--r--doc/en/release-notes/bzr-0.9.txt280
-rw-r--r--doc/en/release-notes/bzr-0.90.txt311
-rw-r--r--doc/en/release-notes/bzr-0.91.txt372
-rw-r--r--doc/en/release-notes/bzr-0.92.txt342
-rw-r--r--doc/en/release-notes/bzr-1.0.txt429
-rw-r--r--doc/en/release-notes/bzr-1.1.txt228
-rw-r--r--doc/en/release-notes/bzr-1.10.txt160
-rw-r--r--doc/en/release-notes/bzr-1.11.txt278
-rw-r--r--doc/en/release-notes/bzr-1.12.txt227
-rw-r--r--doc/en/release-notes/bzr-1.13.txt400
-rw-r--r--doc/en/release-notes/bzr-1.14.txt459
-rw-r--r--doc/en/release-notes/bzr-1.15.txt230
-rw-r--r--doc/en/release-notes/bzr-1.16.txt269
-rw-r--r--doc/en/release-notes/bzr-1.17.txt259
-rw-r--r--doc/en/release-notes/bzr-1.18.txt393
-rw-r--r--doc/en/release-notes/bzr-1.2.txt224
-rw-r--r--doc/en/release-notes/bzr-1.3.txt239
-rw-r--r--doc/en/release-notes/bzr-1.4.txt347
-rw-r--r--doc/en/release-notes/bzr-1.5.txt206
-rw-r--r--doc/en/release-notes/bzr-1.6.txt818
-rw-r--r--doc/en/release-notes/bzr-1.7.txt282
-rw-r--r--doc/en/release-notes/bzr-1.8.txt234
-rw-r--r--doc/en/release-notes/bzr-1.9.txt154
-rw-r--r--doc/en/release-notes/bzr-2.0.txt655
-rw-r--r--doc/en/release-notes/bzr-2.1.txt1305
-rw-r--r--doc/en/release-notes/bzr-2.2.txt1340
-rw-r--r--doc/en/release-notes/bzr-2.3.txt1235
-rw-r--r--doc/en/release-notes/bzr-2.4.txt1356
-rw-r--r--doc/en/release-notes/bzr-2.5.txt1278
-rw-r--r--doc/en/release-notes/bzr-2.6.txt239
-rw-r--r--doc/en/release-notes/release-template.txt53
-rw-r--r--doc/en/release-notes/series-template.txt62
-rw-r--r--doc/en/tutorials/centralized_workflow.txt318
-rw-r--r--doc/en/tutorials/index.txt11
-rw-r--r--doc/en/tutorials/licence.txt7
-rw-r--r--doc/en/tutorials/tutorial.txt647
-rw-r--r--doc/en/tutorials/using_bazaar_with_launchpad.txt488
-rw-r--r--doc/en/upgrade-guide/data_migration.txt217
-rw-r--r--doc/en/upgrade-guide/index.txt15
-rw-r--r--doc/en/upgrade-guide/licence.txt7
-rw-r--r--doc/en/upgrade-guide/overview.txt85
-rw-r--r--doc/en/upgrade-guide/tips_and_tricks.txt35
-rw-r--r--doc/en/user-guide/adv_merging.txt136
-rw-r--r--doc/en/user-guide/annotating_changes.txt35
-rw-r--r--doc/en/user-guide/bazaar_workflows.txt171
-rw-r--r--doc/en/user-guide/branching_a_project.txt129
-rw-r--r--doc/en/user-guide/browsing_history.txt103
-rw-r--r--doc/en/user-guide/bug_trackers.txt56
-rw-r--r--doc/en/user-guide/bzrtools_plugin.txt33
-rw-r--r--doc/en/user-guide/central_intro.txt32
-rw-r--r--doc/en/user-guide/configuring_bazaar.txt167
-rw-r--r--doc/en/user-guide/controlling_registration.txt106
-rw-r--r--doc/en/user-guide/core_concepts.txt123
-rw-r--r--doc/en/user-guide/distributed_intro.txt23
-rw-r--r--doc/en/user-guide/entering_commands.txt41
-rw-r--r--doc/en/user-guide/filtered_views.txt167
-rw-r--r--doc/en/user-guide/getting_help.txt21
-rw-r--r--doc/en/user-guide/gpg_signatures.txt91
-rw-r--r--doc/en/user-guide/hooks.txt115
-rw-r--r--doc/en/user-guide/http_smart_server.txt298
-rw-r--r--doc/en/user-guide/images/workflows_centralized.pngbin0 -> 31331 bytes
-rw-r--r--doc/en/user-guide/images/workflows_centralized.svg1542
-rw-r--r--doc/en/user-guide/images/workflows_gatekeeper.pngbin0 -> 48894 bytes
-rw-r--r--doc/en/user-guide/images/workflows_gatekeeper.svg2137
-rw-r--r--doc/en/user-guide/images/workflows_localcommit.pngbin0 -> 35236 bytes
-rw-r--r--doc/en/user-guide/images/workflows_localcommit.svg1575
-rw-r--r--doc/en/user-guide/images/workflows_peer.pngbin0 -> 33130 bytes
-rw-r--r--doc/en/user-guide/images/workflows_peer.svg1589
-rw-r--r--doc/en/user-guide/images/workflows_pqm.pngbin0 -> 42816 bytes
-rw-r--r--doc/en/user-guide/images/workflows_pqm.svg1794
-rw-r--r--doc/en/user-guide/images/workflows_shared.pngbin0 -> 37509 bytes
-rw-r--r--doc/en/user-guide/images/workflows_shared.svg1594
-rw-r--r--doc/en/user-guide/images/workflows_single.pngbin0 -> 15508 bytes
-rw-r--r--doc/en/user-guide/images/workflows_single.svg1079
-rw-r--r--doc/en/user-guide/index-plain.txt120
-rw-r--r--doc/en/user-guide/index.txt143
-rw-r--r--doc/en/user-guide/installing_bazaar.txt108
-rw-r--r--doc/en/user-guide/introducing_bazaar.txt142
-rw-r--r--doc/en/user-guide/licence.txt7
-rw-r--r--doc/en/user-guide/merging_changes.txt92
-rw-r--r--doc/en/user-guide/organizing_branches.txt100
-rw-r--r--doc/en/user-guide/organizing_your_workspace.txt176
-rw-r--r--doc/en/user-guide/part2_intro.txt16
-rw-r--r--doc/en/user-guide/partner_intro.txt39
-rw-r--r--doc/en/user-guide/plugins.txt98
-rw-r--r--doc/en/user-guide/publishing_a_branch.txt69
-rw-r--r--doc/en/user-guide/recording_changes.txt81
-rw-r--r--doc/en/user-guide/releasing_a_project.txt48
-rw-r--r--doc/en/user-guide/resolving_conflicts.txt83
-rw-r--r--doc/en/user-guide/reusing_a_checkout.txt86
-rw-r--r--doc/en/user-guide/reviewing_changes.txt66
-rw-r--r--doc/en/user-guide/sending_changes.txt71
-rw-r--r--doc/en/user-guide/server.txt105
-rw-r--r--doc/en/user-guide/setting_up_email.txt106
-rw-r--r--doc/en/user-guide/shared_repository_layouts.txt364
-rw-r--r--doc/en/user-guide/shelving_changes.txt110
-rw-r--r--doc/en/user-guide/solo_intro.txt28
-rw-r--r--doc/en/user-guide/specifying_revisions.txt159
-rw-r--r--doc/en/user-guide/stacked.txt136
-rw-r--r--doc/en/user-guide/starting_a_project.txt55
-rw-r--r--doc/en/user-guide/svn_plugin.txt114
-rw-r--r--doc/en/user-guide/undoing_mistakes.txt168
-rw-r--r--doc/en/user-guide/using_aliases.txt63
-rw-r--r--doc/en/user-guide/using_checkouts.txt97
-rw-r--r--doc/en/user-guide/using_gatekeepers.txt44
-rw-r--r--doc/en/user-guide/version_info.txt108
-rw-r--r--doc/en/user-guide/web_browsing.txt15
-rw-r--r--doc/en/user-guide/working_offline_central.txt54
-rw-r--r--doc/en/user-guide/writing_a_plugin.txt62
-rw-r--r--doc/en/user-guide/zen.txt216
-rw-r--r--doc/en/user-reference/readme.txt8
-rw-r--r--doc/en/whats-new/template.txt26
-rw-r--r--doc/en/whats-new/whats-new-in-2.1.txt212
-rw-r--r--doc/en/whats-new/whats-new-in-2.2.txt314
-rw-r--r--doc/en/whats-new/whats-new-in-2.3.txt205
-rw-r--r--doc/en/whats-new/whats-new-in-2.4.txt163
-rw-r--r--doc/en/whats-new/whats-new-in-2.5.txt165
-rw-r--r--doc/en/whats-new/whats-new-in-2.6.txt36
-rw-r--r--doc/es/_static/bzr icon 16.pngbin0 -> 809 bytes
-rw-r--r--doc/es/_static/bzr.icobin0 -> 13094 bytes
-rw-r--r--doc/es/_static/es/Makefile19
-rw-r--r--doc/es/_static/es/bzr-es-quick-reference.pdfbin0 -> 49959 bytes
-rw-r--r--doc/es/_static/es/bzr-es-quick-reference.pngbin0 -> 770184 bytes
-rw-r--r--doc/es/_static/es/bzr-es-quick-reference.svg1691
-rw-r--r--doc/es/_templates/layout.html8
-rw-r--r--doc/es/conf.py99
-rw-r--r--doc/es/index.txt40
-rw-r--r--doc/es/mini-tutorial/index.txt281
-rw-r--r--doc/es/quick-reference/index.txt6
-rw-r--r--doc/es/user-guide/index-plain.txt114
-rw-r--r--doc/es/user-guide/index.txt114
-rw-r--r--doc/es/user-guide/version_info.txt53
-rw-r--r--doc/index.es.txt46
-rw-r--r--doc/index.ja.txt85
-rw-r--r--doc/index.ru.txt63
-rw-r--r--doc/index.txt67
-rw-r--r--doc/ja/_static/bzr icon 16.pngbin0 -> 809 bytes
-rw-r--r--doc/ja/_static/bzr.icobin0 -> 13094 bytes
-rw-r--r--doc/ja/conf.py103
-rw-r--r--doc/ja/index.txt58
-rw-r--r--doc/ja/mini-tutorial/index.txt272
-rw-r--r--doc/ja/tutorials/centralized_workflow.txt283
-rw-r--r--doc/ja/tutorials/index.txt11
-rw-r--r--doc/ja/tutorials/licence.txt14
-rw-r--r--doc/ja/tutorials/tutorial.txt902
-rw-r--r--doc/ja/tutorials/using_bazaar_with_launchpad.txt459
-rw-r--r--doc/ja/upgrade-guide/data_migration.txt132
-rw-r--r--doc/ja/upgrade-guide/index.txt13
-rw-r--r--doc/ja/upgrade-guide/overview.txt77
-rw-r--r--doc/ja/upgrade-guide/tips_and_tricks.txt23
-rw-r--r--doc/ja/user-guide/adv_merging.txt130
-rw-r--r--doc/ja/user-guide/annotating_changes.txt34
-rw-r--r--doc/ja/user-guide/bazaar_workflows.txt181
-rw-r--r--doc/ja/user-guide/branching_a_project.txt118
-rw-r--r--doc/ja/user-guide/browsing_history.txt93
-rw-r--r--doc/ja/user-guide/bug_trackers.txt49
-rw-r--r--doc/ja/user-guide/bzrtools_plugin.txt32
-rw-r--r--doc/ja/user-guide/central_intro.txt32
-rw-r--r--doc/ja/user-guide/configuring_bazaar.txt187
-rw-r--r--doc/ja/user-guide/controlling_registration.txt91
-rw-r--r--doc/ja/user-guide/core_concepts.txt121
-rw-r--r--doc/ja/user-guide/distributed_intro.txt24
-rw-r--r--doc/ja/user-guide/entering_commands.txt36
-rw-r--r--doc/ja/user-guide/filtered_views.txt162
-rw-r--r--doc/ja/user-guide/getting_help.txt22
-rw-r--r--doc/ja/user-guide/hooks.txt125
-rw-r--r--doc/ja/user-guide/http_smart_server.txt295
-rw-r--r--doc/ja/user-guide/images/workflows_centralized.pngbin0 -> 33026 bytes
-rw-r--r--doc/ja/user-guide/images/workflows_centralized.svg1542
-rw-r--r--doc/ja/user-guide/images/workflows_gatekeeper.pngbin0 -> 51025 bytes
-rw-r--r--doc/ja/user-guide/images/workflows_gatekeeper.svg2137
-rw-r--r--doc/ja/user-guide/images/workflows_localcommit.pngbin0 -> 36950 bytes
-rw-r--r--doc/ja/user-guide/images/workflows_localcommit.svg1575
-rw-r--r--doc/ja/user-guide/images/workflows_peer.pngbin0 -> 35417 bytes
-rw-r--r--doc/ja/user-guide/images/workflows_peer.svg1589
-rw-r--r--doc/ja/user-guide/images/workflows_pqm.pngbin0 -> 45702 bytes
-rw-r--r--doc/ja/user-guide/images/workflows_pqm.svg1794
-rw-r--r--doc/ja/user-guide/images/workflows_shared.pngbin0 -> 39066 bytes
-rw-r--r--doc/ja/user-guide/images/workflows_shared.svg1594
-rw-r--r--doc/ja/user-guide/images/workflows_single.pngbin0 -> 17057 bytes
-rw-r--r--doc/ja/user-guide/images/workflows_single.svg1079
-rw-r--r--doc/ja/user-guide/index-plain.txt120
-rw-r--r--doc/ja/user-guide/index.txt141
-rw-r--r--doc/ja/user-guide/installing_bazaar.txt102
-rw-r--r--doc/ja/user-guide/introducing_bazaar.txt118
-rw-r--r--doc/ja/user-guide/licence.txt7
-rw-r--r--doc/ja/user-guide/merging_changes.txt93
-rw-r--r--doc/ja/user-guide/organizing_branches.txt95
-rw-r--r--doc/ja/user-guide/organizing_your_workspace.txt177
-rw-r--r--doc/ja/user-guide/part2_intro.txt11
-rw-r--r--doc/ja/user-guide/partner_intro.txt33
-rw-r--r--doc/ja/user-guide/plugins.txt97
-rw-r--r--doc/ja/user-guide/publishing_a_branch.txt69
-rw-r--r--doc/ja/user-guide/recording_changes.txt76
-rw-r--r--doc/ja/user-guide/releasing_a_project.txt43
-rw-r--r--doc/ja/user-guide/resolving_conflicts.txt75
-rw-r--r--doc/ja/user-guide/reusing_a_checkout.txt83
-rw-r--r--doc/ja/user-guide/reviewing_changes.txt57
-rw-r--r--doc/ja/user-guide/sending_changes.txt65
-rw-r--r--doc/ja/user-guide/server.txt108
-rw-r--r--doc/ja/user-guide/setting_up_email.txt95
-rw-r--r--doc/ja/user-guide/shared_repository_layouts.txt363
-rw-r--r--doc/ja/user-guide/shelving_changes.txt109
-rw-r--r--doc/ja/user-guide/solo_intro.txt23
-rw-r--r--doc/ja/user-guide/specifying_revisions.txt158
-rw-r--r--doc/ja/user-guide/stacked.txt118
-rw-r--r--doc/ja/user-guide/starting_a_project.txt48
-rw-r--r--doc/ja/user-guide/svn_plugin.txt108
-rw-r--r--doc/ja/user-guide/undoing_mistakes.txt152
-rw-r--r--doc/ja/user-guide/using_aliases.txt55
-rw-r--r--doc/ja/user-guide/using_checkouts.txt97
-rw-r--r--doc/ja/user-guide/using_gatekeepers.txt42
-rw-r--r--doc/ja/user-guide/version_info.txt97
-rw-r--r--doc/ja/user-guide/web_browsing.txt16
-rw-r--r--doc/ja/user-guide/working_offline_central.txt50
-rw-r--r--doc/ja/user-guide/writing_a_plugin.txt74
-rw-r--r--doc/ja/user-guide/zen.txt195
-rw-r--r--doc/ja/user-reference/index.txt3855
-rw-r--r--doc/news-template.txt20
-rw-r--r--doc/ru/_static/bzr icon 16.pngbin0 -> 809 bytes
-rw-r--r--doc/ru/_static/bzr.icobin0 -> 13094 bytes
-rw-r--r--doc/ru/_static/ru/Makefile19
-rw-r--r--doc/ru/_static/ru/bzr-ru-quick-reference.pdfbin0 -> 49658 bytes
-rw-r--r--doc/ru/_static/ru/bzr-ru-quick-reference.pngbin0 -> 757142 bytes
-rw-r--r--doc/ru/_static/ru/bzr-ru-quick-reference.svg1601
-rw-r--r--doc/ru/_templates/layout.html8
-rw-r--r--doc/ru/conf.py105
-rw-r--r--doc/ru/index.txt39
-rw-r--r--doc/ru/mini-tutorial/index.txt289
-rw-r--r--doc/ru/quick-reference/index.txt6
-rw-r--r--doc/ru/tutorials/centralized_workflow.txt319
-rw-r--r--doc/ru/tutorials/tutorial.txt591
-rw-r--r--doc/ru/tutorials/using_bazaar_with_launchpad.txt461
-rw-r--r--doc/ru/user-guide/branching_a_project.txt112
-rw-r--r--doc/ru/user-guide/core_concepts.txt115
-rw-r--r--doc/ru/user-guide/images/workflows_centralized.pngbin0 -> 33026 bytes
-rw-r--r--doc/ru/user-guide/images/workflows_centralized.svg1542
-rw-r--r--doc/ru/user-guide/images/workflows_gatekeeper.pngbin0 -> 51025 bytes
-rw-r--r--doc/ru/user-guide/images/workflows_gatekeeper.svg2137
-rw-r--r--doc/ru/user-guide/images/workflows_localcommit.pngbin0 -> 36950 bytes
-rw-r--r--doc/ru/user-guide/images/workflows_localcommit.svg1575
-rw-r--r--doc/ru/user-guide/images/workflows_peer.pngbin0 -> 35417 bytes
-rw-r--r--doc/ru/user-guide/images/workflows_peer.svg1589
-rw-r--r--doc/ru/user-guide/images/workflows_pqm.pngbin0 -> 45702 bytes
-rw-r--r--doc/ru/user-guide/images/workflows_pqm.svg1794
-rw-r--r--doc/ru/user-guide/images/workflows_shared.pngbin0 -> 39066 bytes
-rw-r--r--doc/ru/user-guide/images/workflows_shared.svg1594
-rw-r--r--doc/ru/user-guide/images/workflows_single.pngbin0 -> 17057 bytes
-rw-r--r--doc/ru/user-guide/images/workflows_single.svg1079
-rw-r--r--doc/ru/user-guide/index-plain.txt121
-rw-r--r--doc/ru/user-guide/index.txt121
-rw-r--r--doc/ru/user-guide/introducing_bazaar.txt150
-rw-r--r--doc/ru/user-guide/specifying_revisions.txt153
-rw-r--r--doc/ru/user-guide/stacked.txt84
-rw-r--r--doc/ru/user-guide/using_checkouts.txt98
-rw-r--r--doc/ru/user-guide/zen.txt215
382 files changed, 101016 insertions, 0 deletions
diff --git a/doc/Bazaar-Logo-For-Manuals.png b/doc/Bazaar-Logo-For-Manuals.png
new file mode 100644
index 0000000..9dd8d07
--- /dev/null
+++ b/doc/Bazaar-Logo-For-Manuals.png
Binary files differ
diff --git a/doc/default.css b/doc/default.css
new file mode 100644
index 0000000..1e92ced
--- /dev/null
+++ b/doc/default.css
@@ -0,0 +1,164 @@
+/* from John Arbash Meinel's `Short tutorial' */
+
+body {
+ background-color: #ffffff;
+ color: #303030;
+ margin-top: 50px;
+ margin-left: 50px;
+ margin-right: 50px;
+ margin-bottom: 70px;
+ font-family: Verdana, Geneva, Arial, sans-serif;
+ font-size: small;
+ line-height: 140%
+ }
+
+/* p {
+ text-indent: 3em
+} */
+
+h1, h2, h3 {
+ font-family: Georgia, "Times New Roman", Times, serif;
+}
+
+h1.title {
+ text-align: center;
+ color: #000000;
+ font-size: 1.8em;
+ }
+
+
+div.contents p {
+ font-weight: bold;
+ }
+
+div.contents p a:hover {
+ color: inherit;
+ }
+
+/* Format ".. note:" sections nicely */
+div.note {
+ margin-left: 5em;
+ margin-right: 5em;
+ color: #000000;
+ background-color: #c1d1ff;
+ border: 1px solid #888888;
+ padding-left: 1em;
+ padding-right: 1em;
+ }
+
+div.note .first {
+ font-weight: bold;
+ }
+
+h1 {
+ color: #b52b2b;
+ /* DKREDcolor: #966b72; */
+ /* GREY color: #444444; */
+ font-size: 1.5em;
+ }
+
+h1 a:link {
+ color: inherit;
+ }
+
+h1 a:hover {
+ color: inherit;
+ }
+
+h1 a:visited {
+ color: inherit;
+ }
+
+h2 {
+ color: #222;
+ /* RED color: #966b72; */
+ text-decoration: underline;
+ font-size: 1.4em;
+ }
+
+h2 a:link {
+ color: inherit;
+ }
+
+h2 a:hover {
+ color: inherit;
+ }
+
+h2 a:visited {
+ color: inherit;
+ }
+
+h3 {
+ color: #966b72;
+ /* color: #966b72; */
+ }
+
+h3 a:link {
+ color: inherit;
+ }
+
+h3 a:hover {
+ color: inherit;
+ }
+
+h3 a:visited {
+ color: inherit;
+ }
+
+dt {
+ color: #000000;
+ font-weight: bold;
+ }
+/*
+ border: 4px solid blue;
+ padding: 1ex;
+ background: #7777FF;
+ }
+dt:hover
+ {
+ background-color: black;
+ }
+dt:active
+ {
+ background-color: red;
+ }
+*/
+
+tt, .literal-block {
+ font-family: monospace;
+ line-height: 100%
+ }
+
+tt {
+ color: #000000;
+ font-weight: normal;
+ }
+
+.literal-block {
+ margin-left: 5em;
+ margin-right: 5em;
+ color: #000000;
+ font-weight: normal;
+ background-color: #e5ecf9;
+ border: 1px solid #888888;
+ padding: 1em;
+ }
+
+a:link {
+ color: #4c52ff;
+ text-decoration: none;
+ }
+
+a:visited {
+ color: #4c53ff;
+ text-decoration: none;
+ }
+
+a:hover {
+ color: #b52727;
+ text-decoration: none;
+ }
+
+span, th.field-name {
+ white-space: nowrap;
+}
diff --git a/doc/developers/HACKING.txt b/doc/developers/HACKING.txt
new file mode 100644
index 0000000..bdc562b
--- /dev/null
+++ b/doc/developers/HACKING.txt
@@ -0,0 +1,664 @@
+======================
+Bazaar Developer Guide
+======================
+
+This document describes the Bazaar internals and the development process.
+It's meant for people interested in developing Bazaar, and some parts will
+also be useful to people developing Bazaar plugins.
+
+If you have any questions or something seems to be incorrect, unclear or
+missing, please talk to us in ``irc://irc.freenode.net/#bzr``, or write to
+the Bazaar mailing list. To propose a correction or addition to this
+document, send a merge request or new text to the mailing list.
+
+The latest developer documentation can be found online at
+http://doc.bazaar.canonical.com/developers/.
+
+Getting Started
+###############
+
+Exploring the Bazaar Platform
+=============================
+
+Before making changes, it's a good idea to explore the work already
+done by others. Perhaps the new feature or improvement you're looking
+for is available in another plug-in already? If you find a bug,
+perhaps someone else has already fixed it?
+
+To answer these questions and more, take a moment to explore the
+overall Bazaar Platform. Here are some links to browse:
+
+* The Plugins page on the Wiki - http://wiki.bazaar.canonical.com/BzrPlugins
+
+* The Bazaar product family on Launchpad - https://launchpad.net/bazaar
+
+* Bug Tracker for the core product - https://bugs.launchpad.net/bzr/
+
+If nothing else, perhaps you'll find inspiration in how other developers
+have solved their challenges.
+
+Finding Something To Do
+=======================
+
+Ad-hoc performance work can also be done. One useful tool is the 'evil' debug
+flag. For instance running ``bzr -Devil commit -m "test"`` will log a backtrace
+to the bzr log file for every method call which triggers a slow or non-scalable
+part of the bzr library. So checking that a given command with ``-Devil`` has
+no backtraces logged to the log file is a good way to find problem function
+calls that might be nested deep in the code base.
+
+Planning and Discussing Changes
+===============================
+
+There is a very active community around Bazaar. Mostly we meet on IRC
+(#bzr on irc.freenode.net) and on the mailing list. To join the Bazaar
+community, see http://wiki.bazaar.canonical.com/BzrSupport.
+
+If you are planning to make a change, it's a very good idea to mention it
+on the IRC channel and/or on the mailing list. There are many advantages
+to involving the community before you spend much time on a change.
+These include:
+
+* you get to build on the wisdom of others, saving time
+
+* if others can direct you to similar code, it minimises the work to be done
+
+* it assists everyone in coordinating direction, priorities and effort.
+
+In summary, maximising the input from others typically minimises the
+total effort required to get your changes merged. The community is
+friendly, helpful and always keen to welcome newcomers.
+
+
+Bazaar Development in a Nutshell
+================================
+
+.. was from http://wiki.bazaar.canonical.com/BzrGivingBack
+
+One of the fun things about working on a version control system like Bazaar is
+that the users have a high level of proficiency in contributing back into
+the tool. Consider the following very brief introduction to contributing back
+to Bazaar. More detailed instructions are in the following sections.
+
+Making the change
+-----------------
+
+First, get a local copy of the development mainline (See `Why make a local
+copy of bzr.dev?`_.)
+::
+
+ $ bzr init-repo ~/bzr
+ $ cd ~/bzr
+ $ bzr branch lp:bzr bzr.dev
+
+Now make your own branch::
+
+ $ bzr branch bzr.dev 123456-my-bugfix
+
+This will give you a branch called "123456-my-bugfix" that you can work on
+and commit in. Here, you can study the code, make a fix or a new feature.
+Feel free to commit early and often (after all, it's your branch!).
+
+Documentation improvements are an easy place to get started giving back to the
+Bazaar project. The documentation is in the `doc/` subdirectory of the Bazaar
+source tree.
+
+When you are done, make sure that you commit your last set of changes as well!
+Once you are happy with your changes, ask for them to be merged, as described
+below.
+
+Making a Merge Proposal
+-----------------------
+
+The Bazaar developers use Launchpad to further enable a truly distributed
+style of development. Anyone can propose a branch for merging into the Bazaar
+trunk. To start this process, you need to push your branch to Launchpad. To
+do this, you will need a Launchpad account and user name, e.g.
+`your_lp_username`. You can push your branch to Launchpad directly from
+Bazaar::
+
+ $ bzr push lp:~<your_lp_username>/bzr/meaningful_name_here
+
+After you have pushed your branch, you will need to propose it for merging to
+the Bazaar trunk. Go to
+<https://launchpad.net/~<your_lp_username>/bzr/meaningful_name_here> and choose
+"Propose for merging into another branch". Select "lp:bzr" to hand
+your changes off to the Bazaar developers for review and merging.
+
+Alternatively, after pushing you can use the ``lp-propose`` command to
+create the merge proposal.
+
+Using a meaningful name for your branch will help you and the reviewer(s)
+better track the submission. Use a very succint description of your submission
+and prefix it with bug number if needed (lp:~mbp/bzr/484558-merge-directory
+for example). Alternatively, you can suffix with the bug number
+(lp:~jameinel/bzr/export-file-511987).
+
+
+Review cover letters
+--------------------
+
+Please put a "cover letter" on your merge request explaining:
+
+* the reason **why** you're making this change
+
+* **how** this change achieves this purpose
+
+* anything else you may have fixed in passing
+
+* anything significant that you thought of doing, such as a more
+ extensive fix or a different approach, but didn't or couldn't do now
+
+A good cover letter makes reviewers' lives easier because they can decide
+from the letter whether they agree with the purpose and approach, and then
+assess whether the patch actually does what the cover letter says.
+Explaining any "drive-by fixes" or roads not taken may also avoid queries
+from the reviewer. All in all this should give faster and better reviews.
+Sometimes writing the cover letter helps the submitter realize something
+else they need to do. The size of the cover letter should be proportional
+to the size and complexity of the patch.
+
+
+Why make a local copy of bzr.dev?
+---------------------------------
+
+Making a local mirror of bzr.dev is not strictly necessary, but it means
+
+- You can use that copy of bzr.dev as your main bzr executable, and keep it
+ up-to-date using ``bzr pull``.
+- Certain operations are faster, and can be done when offline. For example:
+
+ - ``bzr bundle``
+ - ``bzr diff -r ancestor:...``
+ - ``bzr merge``
+
+- When it's time to create your next branch, it's more convenient. When you
+ have further contributions to make, you should do them in their own branch::
+
+ $ cd ~/bzr
+ $ bzr branch bzr.dev additional_fixes
+ $ cd additional_fixes # hack, hack, hack
+
+
+
+Understanding the Development Process
+=====================================
+
+The development team follows many practices including:
+
+* a public roadmap and planning process in which anyone can participate
+
+* time based milestones everyone can work towards and plan around
+
+* extensive code review and feedback to contributors
+
+* complete and rigorous test coverage on any code contributed
+
+* automated validation that all tests still pass before code is merged
+ into the main code branch.
+
+The key tools we use to enable these practices are:
+
+* Launchpad - https://launchpad.net/
+
+* Bazaar - http://bazaar.canonical.com/
+
+* Patch Queue Manager - https://launchpad.net/pqm/
+
+For further information, see <http://wiki.bazaar.canonical.com/BzrDevelopment>.
+
+
+
+
+Preparing a Sandbox for Making Changes to Bazaar
+================================================
+
+Bazaar supports many ways of organising your work. See
+http://wiki.bazaar.canonical.com/SharedRepositoryLayouts for a summary of the
+popular alternatives.
+
+Of course, the best choice for you will depend on numerous factors:
+the number of changes you may be making, the complexity of the changes, etc.
+As a starting suggestion though:
+
+* create a local copy of the main development branch (bzr.dev) by using
+ this command::
+
+ bzr branch lp:bzr bzr.dev
+
+* keep your copy of bzr.dev pristine (by not developing in it) and keep
+ it up to date (by using bzr pull)
+
+* create a new branch off your local bzr.dev copy for each issue
+ (bug or feature) you are working on.
+
+This approach makes it easy to go back and make any required changes
+after a code review. Resubmitting the change is then simple with no
+risk of accidentally including edits related to other issues you may
+be working on. After the changes for an issue are accepted and merged,
+the associated branch can be deleted or archived as you wish.
+
+
+Navigating the Code Base
+========================
+
+.. Was at <http://wiki.bazaar.canonical.com/NewDeveloperIntroduction>
+
+Some of the key files in this directory are:
+
+bzr
+ The command you run to start Bazaar itself. This script is pretty
+ short and just does some checks then jumps into bzrlib.
+
+README
+ This file covers a brief introduction to Bazaar and lists some of its
+ key features.
+
+setup.py
+ Installs Bazaar system-wide or to your home directory. To perform
+ development work on Bazaar it is not required to run this file - you
+ can simply run the bzr command from the top level directory of your
+ development copy. Note: That if you run setup.py this will create a
+ 'build' directory in your development branch. There's nothing wrong
+ with this but don't be confused by it. The build process puts a copy
+ of the main code base into this build directory, along with some other
+ files. You don't need to go in here for anything discussed in this
+ guide.
+
+bzrlib
+ Possibly the most exciting folder of all, bzrlib holds the main code
+ base. This is where you will go to edit python files and contribute to
+ Bazaar.
+
+doc
+ Holds documentation on a whole range of things on Bazaar from the
+ origination of ideas within the project to information on Bazaar
+ features and use cases. Within this directory there is a subdirectory
+ for each translation into a human language. All the documentation
+ is in the ReStructuredText markup language.
+
+doc/developers
+ Documentation specifically targeted at Bazaar and plugin developers.
+ (Including this document.)
+
+doc/en/release-notes/
+
+ Detailed changes in each Bazaar release (there is one file by series:
+ bzr-2.3.txt, bzr-2.4.txt, etc) that can affect users or plugin
+ developers.
+
+doc/en/whats-new/
+
+ High-level summaries of changes in each Bazaar release (there is one
+ file by series: whats-new-in-2.3.txt, whats-new-in-2.4.txt, etc).
+
+
+Automatically-generated API reference information is available at
+<http://people.canonical.com/~mwh/bzrlibapi/>.
+
+See also the `Bazaar Architectural Overview
+<http://doc.bazaar.canonical.com/developers/overview.html>`_.
+
+
+Core Topics
+###########
+
+Evolving Interfaces
+===================
+
+We don't change APIs in stable branches: any supported symbol in a stable
+release of bzr must not be altered in any way that would result in
+breaking existing code that uses it. That means that method names,
+parameter ordering, parameter names, variable and attribute names etc must
+not be changed without leaving a 'deprecated forwarder' behind. This even
+applies to modules and classes.
+
+If you wish to change the behaviour of a supported API in an incompatible
+way, you need to change its name as well. For instance, if I add an optional keyword
+parameter to branch.commit - that's fine. On the other hand, if I add a
+keyword parameter to branch.commit which is a *required* transaction
+object, I should rename the API - i.e. to 'branch.commit_transaction'.
+
+ (Actually, that may break code that provides a new implementation of
+ ``commit`` and doesn't expect to receive the parameter.)
+
+When renaming such supported API's, be sure to leave a deprecated_method (or
+_function or ...) behind which forwards to the new API. See the
+bzrlib.symbol_versioning module for decorators that take care of the
+details for you - such as updating the docstring, and issuing a warning
+when the old API is used.
+
+For unsupported API's, it does not hurt to follow this discipline, but it's
+not required. Minimally though, please try to rename things so that
+callers will at least get an AttributeError rather than weird results.
+
+
+Deprecation decorators
+----------------------
+
+``bzrlib.symbol_versioning`` provides decorators that can be attached to
+methods, functions, and other interfaces to indicate that they should no
+longer be used. For example::
+
+ @deprecated_method(deprecated_in((0, 1, 4)))
+ def foo(self):
+ return self._new_foo()
+
+To deprecate a static method you must call ``deprecated_function``
+(**not** method), after the staticmethod call::
+
+ @staticmethod
+ @deprecated_function(deprecated_in((0, 1, 4)))
+ def create_repository(base, shared=False, format=None):
+
+When you deprecate an API, you should not just delete its tests, because
+then we might introduce bugs in them. If the API is still present at all,
+it should still work. The basic approach is to use
+``TestCase.applyDeprecated`` which in one step checks that the API gives
+the expected deprecation message, and also returns the real result from
+the method, so that tests can keep running.
+
+Deprecation warnings will be suppressed for final releases, but not for
+development versions or release candidates, or when running ``bzr
+selftest``. This gives developers information about whether their code is
+using deprecated functions, but avoids confusing users about things they
+can't fix.
+
+
+General Guidelines
+==================
+
+Copyright
+---------
+
+The copyright policy for bzr was recently made clear in this email (edited
+for grammatical correctness)::
+
+ The attached patch cleans up the copyright and license statements in
+ the bzr source. It also adds tests to help us remember to add them
+ with the correct text.
+
+ We had the problem that lots of our files were "Copyright Canonical
+ Development Ltd" which is not a real company, and some other variations
+ on this theme. Also, some files were missing the GPL statements.
+
+ I want to be clear about the intent of this patch, since copyright can
+ be a little controversial.
+
+ 1) The big motivation for this is not to shut out the community, but
+ just to clean up all of the invalid copyright statements.
+
+ 2) It has been the general policy for bzr that we want a single
+ copyright holder for all of the core code. This is following the model
+ set by the FSF, which makes it easier to update the code to a new
+ license in case problems are encountered. (For example, if we want to
+ upgrade the project universally to GPL v3 it is much simpler if there is
+ a single copyright holder). It also makes it clearer if copyright is
+ ever debated, there is a single holder, which makes it easier to defend
+ in court, etc. (I think the FSF position is that if you assign them
+ copyright, they can defend it in court rather than you needing to, and
+ I'm sure Canonical would do the same).
+ As such, Canonical has requested copyright assignments from all of the
+ major contributers.
+
+ 3) If someone wants to add code and not attribute it to Canonical, there
+ is a specific list of files that are excluded from this check. And the
+ test failure indicates where that is, and how to update it.
+
+ 4) If anyone feels that I changed a copyright statement incorrectly, just
+ let me know, and I'll be happy to correct it. Whenever you have large
+ mechanical changes like this, it is possible to make some mistakes.
+
+ Just to reiterate, this is a community project, and it is meant to stay
+ that way. Core bzr code is copyright Canonical for legal reasons, and
+ the tests are just there to help us maintain that.
+
+
+Miscellaneous Topics
+####################
+
+Debugging
+=========
+
+Bazaar has a few facilities to help debug problems by going into pdb_, the
+Python debugger.
+
+.. _pdb: http://docs.python.org/lib/debugger-commands.html
+
+If the ``BZR_PDB`` environment variable is set
+then bzr will go into pdb post-mortem mode when an unhandled exception
+occurs.
+
+If you send a SIGQUIT or SIGBREAK signal to bzr then it will drop into the
+debugger immediately. SIGQUIT can be generated by pressing Ctrl-\\ on
+Unix. SIGBREAK is generated with Ctrl-Pause on Windows (some laptops have
+this as Fn-Pause). You can continue execution by typing ``c``. This can
+be disabled if necessary by setting the environment variable
+``BZR_SIGQUIT_PDB=0``.
+
+All tests inheriting from bzrlib.tests.TestCase can use ``self.debug()``
+instead of the longer ``import pdb; pdb.set_trace()``. The former also works
+when ``stdin/stdout`` are redirected (by using the original ``stdin/stdout``
+file handles at the start of the ``bzr`` script) while the later doesn't.
+``bzrlib.debug.set_trace()`` also uses the original ``stdin/stdout`` file
+handles.
+
+Debug Flags
+===========
+
+Bazaar accepts some global options starting with ``-D`` such as
+``-Dhpss``. These set a value in `bzrlib.debug.debug_flags`, and
+typically cause more information to be written to the trace file. Most
+`mutter` calls should be guarded by a check of those flags so that we
+don't write out too much information if it's not needed.
+
+Debug flags may have effects other than just emitting trace messages.
+
+Run ``bzr help global-options`` to see them all.
+
+These flags may also be set as a comma-separated list in the
+``debug_flags`` option in e.g. ``~/.bazaar/bazaar.conf``. (Note that it
+must be in this global file, not in the branch or location configuration,
+because it's currently only loaded at startup time.) For instance you may
+want to always record hpss traces and to see full error tracebacks::
+
+ debug_flags = hpss, error
+
+
+Jargon
+======
+
+revno
+ Integer identifier for a revision on the main line of a branch.
+ Revision 0 is always the null revision; others are 1-based
+ indexes into the branch's revision history.
+
+
+Unicode and Encoding Support
+============================
+
+This section discusses various techniques that Bazaar uses to handle
+characters that are outside the ASCII set.
+
+``Command.outf``
+----------------
+
+When a ``Command`` object is created, it is given a member variable
+accessible by ``self.outf``. This is a file-like object, which is bound to
+``sys.stdout``, and should be used to write information to the screen,
+rather than directly writing to ``sys.stdout`` or calling ``print``.
+This file has the ability to translate Unicode objects into the correct
+representation, based on the console encoding. Also, the class attribute
+``encoding_type`` will effect how unprintable characters will be
+handled. This parameter can take one of 3 values:
+
+ replace
+ Unprintable characters will be represented with a suitable replacement
+ marker (typically '?'), and no exception will be raised. This is for
+ any command which generates text for the user to review, rather than
+ for automated processing.
+ For example: ``bzr log`` should not fail if one of the entries has text
+ that cannot be displayed.
+
+ strict
+ Attempting to print an unprintable character will cause a UnicodeError.
+ This is for commands that are intended more as scripting support, rather
+ than plain user review.
+ For example: ``bzr ls`` is designed to be used with shell scripting. One
+ use would be ``bzr ls --null --unknowns | xargs -0 rm``. If ``bzr``
+ printed a filename with a '?', the wrong file could be deleted. (At the
+ very least, the correct file would not be deleted). An error is used to
+ indicate that the requested action could not be performed.
+
+ exact
+ Do not attempt to automatically convert Unicode strings. This is used
+ for commands that must handle conversion themselves.
+ For example: ``bzr diff`` needs to translate Unicode paths, but should
+ not change the exact text of the contents of the files.
+
+
+``bzrlib.urlutils.unescape_for_display``
+----------------------------------------
+
+Because Transports work in URLs (as defined earlier), printing the raw URL
+to the user is usually less than optimal. Characters outside the standard
+set are printed as escapes, rather than the real character, and local
+paths would be printed as ``file://`` URLs. The function
+``unescape_for_display`` attempts to unescape a URL, such that anything
+that cannot be printed in the current encoding stays an escaped URL, but
+valid characters are generated where possible.
+
+
+C Extension Modules
+===================
+
+We write some extensions in C using pyrex. We design these to work in
+three scenarios:
+
+ * User with no C compiler
+ * User with C compiler
+ * Developers
+
+The recommended way to install bzr is to have a C compiler so that the
+extensions can be built, but if no C compiler is present, the pure python
+versions we supply will work, though more slowly.
+
+For developers we recommend that pyrex be installed, so that the C
+extensions can be changed if needed.
+
+For the C extensions, the extension module should always match the
+original python one in all respects (modulo speed). This should be
+maintained over time.
+
+To create an extension, add rules to setup.py for building it with pyrex,
+and with distutils. Now start with an empty .pyx file. At the top add
+"include 'yourmodule.py'". This will import the contents of foo.py into this
+file at build time - remember that only one module will be loaded at
+runtime. Now you can subclass classes, or replace functions, and only your
+changes need to be present in the .pyx file.
+
+Note that pyrex does not support all 2.4 programming idioms, so some
+syntax changes may be required. I.e.
+
+ - 'from foo import (bar, gam)' needs to change to not use the brackets.
+ - 'import foo.bar as bar' needs to be 'import foo.bar; bar = foo.bar'
+
+If the changes are too dramatic, consider
+maintaining the python code twice - once in the .pyx, and once in the .py,
+and no longer including the .py file.
+
+
+Making Installers for OS Windows
+================================
+To build a win32 installer, see the instructions on the wiki page:
+http://wiki.bazaar.canonical.com/BzrWin32Installer
+
+Core Developer Tasks
+####################
+
+Overview
+========
+
+What is a Core Developer?
+-------------------------
+
+While everyone in the Bazaar community is welcome and encouraged to
+propose and submit changes, a smaller team is reponsible for pulling those
+changes together into a cohesive whole. In addition to the general developer
+stuff covered above, "core" developers have responsibility for:
+
+* reviewing changes
+* planning releases
+* managing releases (see `Releasing Bazaar <http://doc.bazaar.canonical.com/developers/releasing.html>`_)
+
+.. note::
+ Removing barriers to community participation is a key reason for adopting
+ distributed VCS technology. While DVCS removes many technical barriers,
+ a small number of social barriers are often necessary instead.
+ By documenting how the above things are done, we hope to
+ encourage more people to participate in these activities, keeping the
+ differences between core and non-core contributors to a minimum.
+
+
+Communicating and Coordinating
+------------------------------
+
+While it has many advantages, one of the challenges of distributed
+development is keeping everyone else aware of what you're working on.
+There are numerous ways to do this:
+
+#. Assign bugs to yourself in Launchpad
+#. Mention it on the mailing list
+#. Mention it on IRC
+
+As well as the email notifcations that occur when merge requests are sent
+and reviewed, you can keep others informed of where you're spending your
+energy by emailing the **bazaar-commits** list implicitly. To do this,
+install and configure the Email plugin. One way to do this is add these
+configuration settings to your central configuration file (e.g.
+``~/.bazaar/bazaar.conf``)::
+
+ [DEFAULT]
+ email = Joe Smith <joe.smith@internode.on.net>
+ smtp_server = mail.internode.on.net:25
+
+Then add these lines for the relevant branches in ``locations.conf``::
+
+ post_commit_to = bazaar-commits@lists.canonical.com
+ post_commit_mailer = smtplib
+
+While attending a sprint, RobertCollins' Dbus plugin is useful for the
+same reason. See the documentation within the plugin for information on
+how to set it up and configure it.
+
+
+
+Planning Releases
+=================
+
+
+Bug Triage
+----------
+
+Keeping on top of bugs reported is an important part of ongoing release
+planning. Everyone in the community is welcome and encouraged to raise
+bugs, confirm bugs raised by others, and nominate a priority. Practically
+though, a good percentage of bug triage is often done by the core
+developers, partially because of their depth of product knowledge.
+
+With respect to bug triage, core developers are encouraged to play an
+active role with particular attention to the following tasks:
+
+* keeping the number of unconfirmed bugs low
+* ensuring the priorities are generally right (everything as critical - or
+ medium - is meaningless)
+* looking out for regressions and turning those around sooner rather than later.
+
+.. note::
+ As well as prioritizing bugs and nominating them against a
+ target milestone, Launchpad lets core developers offer to mentor others in
+ fixing them.
+
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/_static/bzr icon 16.png b/doc/developers/_static/bzr icon 16.png
new file mode 100644
index 0000000..0c8d454
--- /dev/null
+++ b/doc/developers/_static/bzr icon 16.png
Binary files differ
diff --git a/doc/developers/_static/bzr-doc.css b/doc/developers/_static/bzr-doc.css
new file mode 100644
index 0000000..6d1a94b
--- /dev/null
+++ b/doc/developers/_static/bzr-doc.css
@@ -0,0 +1,4 @@
+
+ol.loweralpha {
+ list-style-type: lower-alpha;
+}
diff --git a/doc/developers/_static/bzr.ico b/doc/developers/_static/bzr.ico
new file mode 100644
index 0000000..a49eb7e
--- /dev/null
+++ b/doc/developers/_static/bzr.ico
Binary files differ
diff --git a/doc/developers/_templates/layout.html b/doc/developers/_templates/layout.html
new file mode 100644
index 0000000..a34680b
--- /dev/null
+++ b/doc/developers/_templates/layout.html
@@ -0,0 +1,13 @@
+{% extends "!layout.html" %}
+
+{% block linktags %}
+{{ super() }}
+<link rel="stylesheet" href="_static/bzr-doc.css" type="text/css" />
+{% endblock %}
+
+{% block rootrellink %}
+<li><a href="http://bazaar.canonical.com/">
+ <img src="{{ pathto("_static/bzr icon 16.png", 1) }}" /> Home</a>&nbsp;|&nbsp;</li>
+<a href="http://doc.bazaar.canonical.com/en/">Documentation</a>&nbsp;|&nbsp;</li>
+{{ super() }}
+{% endblock %}
diff --git a/doc/developers/add.txt b/doc/developers/add.txt
new file mode 100644
index 0000000..543e54f
--- /dev/null
+++ b/doc/developers/add.txt
@@ -0,0 +1,34 @@
+Add
+===
+
+Add is used to recursively version some paths supplied by the user. Paths that
+match ignore rules are not versioned, and paths that become versioned are
+versioned in the nearest containing bzr tree. Currently we only do this within
+a single tree, but perhaps with nested trees this should change.
+
+Least work we can hope to perform
+---------------------------------
+
+* Read a subset of the full versioned paths data for the tree matching the scope of the paths the user supplied.
+* Seek once to each directory within the scope and readdir its contents.
+* Probe if each directory is a child tree to avoid adding data for paths within a child tree.
+* Calculate the ignored status for paths not previously known to be ignored
+* Write data proportional to the newly versioned file count to record their versioning.
+* Assign a fileid for each path (so that merge --uncommitted can work immediately)
+
+Optionally:
+
+* Print the ignore rule for each ignored path in the scope.
+* Print the path of each added file.
+* Print the total count of ignored files within the scopes.
+* Record the result of calculating ignored status for ignored files.
+ (proportional to the number we actually calculate).
+
+Per file algorithm
+------------------
+
+#. If the path is versioned, and it is a directory, push onto the recurse stack.
+#. If the path is supplied by the user or is not ignored, version it, and if a
+ directory, push onto the recurse stack. Versioning the path may require
+ versioning the paths parents.
+#. Output or otherwise record the ignored rule as per the user interface selected.
diff --git a/doc/developers/annotate.txt b/doc/developers/annotate.txt
new file mode 100644
index 0000000..ebcd86f
--- /dev/null
+++ b/doc/developers/annotate.txt
@@ -0,0 +1,28 @@
+Annotate
+========
+
+Broadly tries to ascribe parts of the tree state to individual commits.
+
+There appear to be three basic ways of generating annotations:
+
+If the annotation works by asking the storage layer for successive full texts
+then the scaling of this will be proportional to the time to diff throughout
+the history of thing being annotated.
+
+If the annotation works by asking the storage layer for successive deltas
+within the history of the thing being annotated we believe we can make it scale
+broadly proportional to the depth of the tree of revisions of the annotated
+object.
+
+If the annotation works by combining cached annotations such that creating a
+full text recreates annotations for it then it will scale with the cost of
+obtaining that text.
+
+Generally we want our current annotations but it would be nice to be able to do
+whitespace annotations and potentially other diff based annotations.
+
+Some things to think about:
+
+ * Perhaps multiparent deltas would allow us to not store the cached
+ annotations in each delta without losing performance or accuracy.
+
diff --git a/doc/developers/api-versioning.txt b/doc/developers/api-versioning.txt
new file mode 100644
index 0000000..912027b
--- /dev/null
+++ b/doc/developers/api-versioning.txt
@@ -0,0 +1,133 @@
+==============
+API Versioning
+==============
+
+Status
+======
+
+:Date: 2007-06-26
+
+bzrlib has a rich API which is used both internally, and externally by
+plugins_ and scripts. To allow the API to change, specifically to allow
+support for features and methods to be removed, without causing hard to
+diagnose bugs in the clients of the API, bzrlib provides explicit API
+compatibility data, and a compact API to allow scripts and plugins to
+ascertain if the bzrlib they are using is compatible to the API they were
+written against.
+
+
+.. _plugins: plugin-api.html
+
+
+.. contents::
+
+
+Motivation
+==========
+
+To allow plugins to apply their own policy for compatibility with bzrlib,
+without requiring a new release on every library release. Plugins should
+also be able to use the API to export their own compatibility information
+for code reuse between plugins.
+
+
+Terminology
+===========
+
+An **API** is a collection of python objects/modules/packages which can be
+used by plugins and scripts. The ``bzrlib`` **API** covers all of bzrlib,
+but we can be more precise - e.g. the ``WorkingTree API``.
+An **API version** is a tuple ``(major, minor, point)``.
+
+
+API versions
+============
+
+For simplicity we treat API's as being compatible with a range of
+versions: the current release of the API, and some oldest version which is
+also compatible. While we could say that there is a set of older versions
+with which the current version is compatible, a range is easier to
+express, and easier for a human to look at and understand, and finally
+easier to manage. The oldest version with which the API for a python
+object is compatible is obtained by looking up the ``api_minimum_version``
+attribute on the python object handed to ``require_api``, and failing that
+the bzrlib ``api_minimum_version`` is returned. The current version of the
+API is obtained by looking for an ``api_current_version`` attribute, and
+if that is not found, an ``version_info`` attribute (of which the first 3
+elements are used). If no current version can be found, the bzrlib
+``version_info`` attribute is used to generate a current API version.
+This lookup sequence allows users with simple setups (and no python style
+``version_info`` tuple) to still export an API version, and for new API's
+to be managed more granularly later on with a smooth transition -
+everything starts off in lockstep with bzrlib's master version.
+
+API versions are compared lexically to answer the question 'is
+the requested version X <= the current version, and >= the minimum
+version'.
+
+Managing API versions
+=====================
+
+The minimum API versions should be adjusted to the **oldest** API version
+with which client code of the API will successfully run. It should not be
+changed simply because of adding things in a compatible manner, or
+deprecating features, but rather when errors will occur if client code is
+not updated. Versions for API's from ``bzrlib`` are given the version
+numbers that ``bzrlib`` has had for consistency. Plugins should also take
+this approach and use the version numbering scheme the plugin used.
+
+Exported API's
+==============
+
+Currently we export a single API - the ``bzrlib API`` - and no finer
+grained APIs. The API versioning support was introduced in bzrlib 0.18.
+For plugins or tools that want to dynamically check for the presence of
+the API versioning API, you should compare ``bzrlib.version_info[0:3]``
+with ``(0, 18, 0)``.
+
++------------+---------------+
+| API | Covers |
++============+===============+
+| bzrlib | All of bzrlib |
++------------+---------------+
+
+Use Cases
+=========
+
+Some examples of using the API.
+
+Requiring bzrlib 0.18 in a plugin
+---------------------------------
+
+In the plugins __init__.py::
+
+ import bzrlib
+ from bzrlib.api import require_api
+ from bzrlib.errors import IncompatibleAPI
+ try:
+ require_api(bzrlib, (0, 18, 0))
+ except IncompatibleAPI:
+ raise ImportError("A bzrlib compatible with 0.18 is required.")
+
+Exporting an API from a plugin
+------------------------------
+
+In the plugin ``foo`` exporting the API (in __init__.py)::
+
+ version_info = (0, 0, 1, 'beta', 1)
+ api_version = (0, 0, 1)
+
+In a plugin depending on that plugin (in __init__.py)::
+
+ import bzrlib.plugins.foo
+ from bzrlib.api import require_api
+ from bzrlib.errors import IncompatibleAPI
+ try:
+ require_api(bzrlib.plugins.foo, (0, 0, 1))
+ except IncompatibleAPI:
+ raise ImportError("A bzrlib compatible with 0.0.1 is required.")
+
+
+..
+ vim: ft=rst tw=74 ai
+
diff --git a/doc/developers/apport.txt b/doc/developers/apport.txt
new file mode 100644
index 0000000..f7785a4
--- /dev/null
+++ b/doc/developers/apport.txt
@@ -0,0 +1,87 @@
+*************************
+Bazaar Apport Integration
+*************************
+
+Bazaar can use Apport <http://launchpad.net/apport/> to capture data about
+unexpected errors (probably, bugs in Bazaar) and report them to the
+developers.
+
+This is only active for errors that are believed to be internal errors (ie
+bugs) not user or environmental errors. (See the Developer Guide.)
+
+Consequences for users
+----------------------
+
+* They shouldn't normally need to see or copy&paste a traceback.
+
+* They will be able to inspect the files before sending them to be sure
+ there's no sensitive data included.
+
+* As at present, they'll need a Launchpad account to report bugs in the
+ normal way.
+
+
+Implementation notes
+--------------------
+
+The use of apport by Bazaar is independent of the configuration in the OS.
+For example in Ubuntu, apport is normally inactive in release builds, and
+normally excludes software not installed from a package. We'll bypass
+both of them.
+
+Putting in this handler may mean that an OS-wide exception handler never
+sees the error, but that was true with our existing exception-printer.
+
+The user should have the option to: forget about the crash (and ignore the
+bug report), see the contents of the report, file a bug, or save the
+report to file later. At the moment we just show them the filename and
+let them take it from there.
+
+The process is
+
+#. An exception reaches the top-level handler.
+
+#. We log it in apport-format to a file in ~/.bazaar/crash.
+
+#. We tell the user where that file is, and invite them to file a bug
+ report.
+
+This won't be active for bugs that cause the whole Python interpreter to
+crash. This can be handled at the OS level. The nice thing is that if
+apport is active system-wide, it will catch either exceptions in our
+in-process apport handler, or errors that crash the intrepreter.
+
+
+Future ideas
+------------
+
+* Capture apport data even for things not believed to be internal errors,
+ because sometimes they are in fact bugs. Then the user can attach the
+ apport report later if they decide to file a bug. There may be quite a
+ lot of them so we might need to limit the number that are stored, or do
+ this when a debug flag is set. At the moment they go into .bzr.log and
+ that's probably ok to start with.
+
+* Raising an error from the breakin debugger should cause this to fire.
+
+* Developers looking at a crash on their own machine will probably in the
+ first instance just want to see the traceback. Apport files may be more
+ longwinded than our current output and might make the traceback scroll
+ off the screen.
+
+* Automatically trace messages (ie from .bzr.log) in the report. We could
+ just include the whole file, but it may be long, and including the whole
+ thing has a greater risk of including sensitive data.
+
+* Ask the user what they want to do with the report: automatically file
+ it, look at it, see just the traceback, just be told where it is. This
+ could be done through the UIFactory so that it can be done through a
+ graphical dialog.
+
+ However, if we've already had an unhandled error in this process there
+ may be problems in Bazaar that prevent us presenting a clean message...
+
+ Possibly these bugs are better reported in the next time bzr runs.
+
+..
+ vim: ft=rst
diff --git a/doc/developers/authentication-ring.txt b/doc/developers/authentication-ring.txt
new file mode 100644
index 0000000..a1dbb04
--- /dev/null
+++ b/doc/developers/authentication-ring.txt
@@ -0,0 +1,418 @@
+Authentication ring
+===================
+
+When accessing a remote branch (specified as an URL), it may occur that the
+server requests an authentication.
+
+This authentication can be provided in different ways:
+
+1. Embedding the user and password
+in the URL::
+
+ bzr branch <scheme>://<user>:<password>@host:port/path
+
+* ``scheme``: Any transport protocol requiring authentication.
+* ``user``: The login used to authenticate.
+* ``password``: The associated password.
+* ``host``: The address of the server.
+* ``port``: The port the server is listening to.
+* ``path``: The path on the server.
+
+2. Embedding the user in the URL and let bzr find the right password or prompt
+for one::
+
+ bzr branch <scheme>://<user>@host/path
+
+3. Embedding nothing in the URL and let bzr find user and password or prompt
+for user and/or password::
+
+ bzr branch <scheme>://host/path
+
+This specification proposes a mechanism that will allow users to
+just use ``bzr branch <scheme>://host/path`` or ``bzr branch
+<scheme>://<user>@host/path`` and leaves bzr find the ``user``
+and ``password`` in its configuration files.
+
+When no user is specified for ``FTP``, ``SFTP`` or ``SSH``, the actual behavior
+of ``bzr`` is to default to ``getpass.get_user()``.
+
+Any implementation of this specification should respect that behaviour.
+
+This specification also proposes a way to describe credentials so that several
+remote branches can use the same definition. This is particularily important
+for users handling a lot of passwords and who need to update them on a regular
+basis.
+
+Rationale
+---------
+
+Embedding user and passwords in the command line is a security
+hazard (see `bug #34685
+<https://launchpad.net/products/bzr/+bug/34685>`_).
+
+Storing passwords in ``~/.bazaar/bazaar.conf`` or ``~/.bazaar/locations.conf``
+is also a security risk.
+
+Typing user and passwords is error-prone and boring.
+
+Yet, a safe way to store passwords, while allowing bzr to retrieve them, when
+needed, could improve the bzr user experience.
+
+This specification describes a way to provide user and passwords to bzr while
+storing them in a relatively safe way.
+
+Note that SSH servers can be configured to use keys instead of (``user``,
+``password``) and, when used with appropriate agents, provide the same kind of
+comfort this specification aims to provide for all other schemes. Since SSH
+agents provide a safer way to secure the passwords, this specification is
+restricted to providing ``user`` but does not provide ``password`` when used
+for SSH.
+
+Authentication definitions
+--------------------------
+
+There are two kinds of authentication used by the various schemes supported by
+bzr:
+
+1. user and password
+
+``FTP`` and ``SFTP`` needs a (``user``, ``password``) to authenticate against a
+``host`` (SFTP can use SSH keys too, but we don't talk about that in this
+specification as SSH agents provide a better solution).
+
+2. user, realm and password
+
+``HTTP`` and ``HTTPS`` needs a (``user, realm, password``) to authenticate
+against a host. But, by using ``.htaccess`` files, for example, it is possible
+to define several (``user, realm, password``) for a given ``host``. So what is
+really needed is (``user``, ``password``, ``host``, ``path``). The ``realm``
+can be ignored [#ignored_realm]_ as long as it is still presented to the user
+when prompting for the password (unless someone found a way to declare two
+different realms for the same path).
+
+``HTTP proxy`` can be handled as ``HTTP`` (or ``HTTPS``) by explicitly
+specifying the appropriate port.
+
+.. [#ignored_realm] The true purpose of realms is to allow the same credentials
+ to be reused for disjoint hierarchies. Ignoring them in this specification
+ aims to simplify the user experience while still allowing to share the same
+ credentials for a whole hierarchy.
+
+To take all schemes into account, the password will be deduced from a set of
+authentication definitions (``scheme``, ``host``, ``port``, ``path``, ``user``,
+``password``).
+
+ * ``scheme``: can be empty (meaning the rest of the definition can be used
+ for any scheme), ``SFTP`` and ``bzr+ssh`` should not be used here, ``ssh``
+ should be used instead since this is the real scheme regarding
+ authentication,
+
+ * ``host``: can be empty (to act as a default for any host),
+
+ * ``port`` can be empty (useful when an host provides several servers for the
+ same scheme), only numerical values are allowed, this should be used only
+ when the server uses a port different than the scheme standard port,
+
+ * ``path``: can be empty (FTP or SFTP will never use it),
+
+ * ``user``: can be empty (``bzr`` will defaults to Python's
+ ``getpass.get_user()`` for FTP, SFTP and SSH),
+
+ * ``password``: can be empty (for security reasons, a user may use the
+ definitions without storing the passwords but want to be prompted ; or the
+ password will be provided by an external plugin via the
+ ``password_encoding`` mechanism decribed below). Must be left empty for
+ ``ssh``.
+
+ * ``password_encoding``: can be empty (default is ``plaintext``).
+
+Also note that an optional ``verify_certificates=no`` field will allow the
+connection to ``HTTPS`` hosts that provides a self certified certificate (the
+default should be to refuse the connection and inform the user). (Not
+implemented yet)
+
+Multiple definitions can be provided and, for a given URL, bzr will select a
+(``user`` [, ``password``]) based on the following rules :
+
+ 1. the first match wins,
+
+ 2. empty fields match everything,
+
+ 3. ``scheme`` matches even if decorators are used in the requested URL,
+
+ 4. ``host`` matches exactly or act as a domain if it starts with '.'
+ (``project.bzr.sf.net`` will match ``.bzr.sf.net`` but ``projectbzr.sf.net``
+ will not match ``bzr.sf.net``).
+
+ 5. ``port`` matches if included in the requested URL (exact matches only)
+
+ 6. ``path`` matches if included in the requested URL (and by rule #2 above,
+ empty paths will match any provided path).
+
+An optional ``password_encoding`` field may specify how the password is encoded
+but has no impact on the definition selection.
+
+Possible values are ``plaintext`` (no encoding at all) and ``base64``. When the
+field is absent, ``plaintext`` is assumed. Additional encodings may be added in
+future versions.
+
+Encoding passwords in ``base64``, while weak, provides protection against
+accidental reading (if an administrator have to look into the file, he will not
+see the passwords in clear).(Not implemented yet).
+
+This specification intends to ease the authentication providing, not to secure
+it in the best possible way.
+
+Plugins can provide additional password encodings. The provided
+``netrc_credential_store`` plugin can be used as an example implementation.
+
+Future versions of this specification may provide additional
+encodings [#password_encoding]_.
+
+.. [#password_encoding] Additional password encoding methods may be defined
+ that will rely on external means to store the password which, in these
+ cases, will not appear anymore in the definition. It is assumed that
+ additional password encodings will provide a storage outside of the file
+ described here. The ``netrc`` encoding, for example, provides passwords by
+ retrieving them from the ``.netrc`` file.
+
+File format
+-----------
+
+Even if ``~/.bazaar/bazaar.conf`` and ``~/.bazaar/locations.conf`` seems to
+provide most of the needed infrastructure, we choose to use a dedicated file
+for the authentication info ``~/.bazaar/authentication.conf`` for the following
+reasons:
+
+ * allow the user to protect the content of one file only, relaxing security
+ constraints on the others,
+
+ * while ``locations.conf`` is organized around *local* branches,
+ ``authentication.conf`` is organized around *remote* branches or more
+ generally servers. The same authentification definition can even be used
+ for several schemes for servers providing those schemes.
+
+``~/.bazaar/authentication.conf`` will use the same file format as
+``~/.bazaar/bazaar.conf``.
+
+Each section describes an authentication definition.
+
+The section name is an arbitrary string, only the ``DEFAULT`` value is reserved
+and should appear as the *last* section.
+
+Each section should define:
+
+ * ``user``: the login to be used,
+
+Each section could define:
+
+ * ``host``: the remote server,
+
+ * ``port``: the port the server is listening,
+
+ * ``verify_certificates``: to control certificate verification (useful
+ for self certified hosts). This applies to HTTPS only. Accepted values
+ are yes and no, default to yes.
+
+ * ``path``: the branch location,
+
+ * ``password``: the password,
+
+ * ``password_encoding``: the method used to encode the password if any,
+
+The default content of the file will be::
+
+ [DEFAULT]
+
+This section could define:
+
+ * ``user``: default user to be used (if not defined the usual
+ bzr way applies, see below).
+
+ * ``password_encoding``: default password encoding.
+
+Use Cases
+---------
+
+The use cases described below use the file format defined above.
+
+ * all FTP connections to the foo.net domain are done with the same (``user``,
+ ``password``)::
+
+ # Identity on foo.net
+ [foo.net]
+ scheme=ftp
+ host=foo.net
+ user=joe
+ password=secret-pass
+
+ will provide ('joe', 'secret-pass') for::
+
+ bzr branch ftp://foo.net/bzr/branch
+ bzr pull ftp://bzr.foo.net/bzr/product/branch/trunk
+
+ * all connections are done with the same ``user`` (the remote one for which
+ the default bzr one is not appropriate) and the password is always prompted
+ with some exceptions::
+
+ # Pet projects on hobby.net
+ [hobby]
+ host=r.hobby.net
+ user=jim
+ password=obvious1234
+
+ # Home server
+ [home]
+ scheme=https
+ host=home.net
+ user=joe
+ password='c2VjcmV0LXBhc3M='
+ password_encoding=base64
+ verify_certificates=no # Still searching a free certificate provider
+
+ [DEFAULT]
+ # Our local user is barbaz, on all remote sites we're known as foobar
+ user=foobar
+
+ * an HTTP server and a proxy::
+
+ # development branches on dev server
+ [dev]
+ scheme=https
+ host=dev.company.com
+ path=/dev
+ user=user1
+ password=pass1
+
+ # toy branches
+ [localhost]
+ scheme=http
+ host=dev.company.com
+ path=/
+ user=user2
+ password=pass2
+
+ # proxy
+ [proxy]
+ scheme=http
+ host=proxy.company.com
+ port=3128
+ user=proxyuser1
+ password=proxypass1
+
+ * source hosting provider declaring sub-domains for each project::
+
+ [sfnet domain]
+ # we use SFTP, but SSH is the scheme used for authentication
+ scheme=ssh
+ # The leading '.' ensures that 'sf.net' alone doesn't match
+ host=.sf.net
+ user=georges
+ password=ben...son
+
+
+UI Changes
+----------
+
+Depending on the info provided in the URL, bzr will interact with the user in
+different ways:
+
+1. ``user`` and ``password`` given in the URL.
+
+ Nothing to do.
+
+2. ``user`` given in the URL.
+
+ Get a password from ``~/.bazaar/authentication.conf`` or prompt
+ for one if none is found.
+
+3. No ``user`` given in the URL (and no ``password``).
+
+ Get a user from ``~/.bazaar/authentication.conf`` or prompt for one if none is
+ found. Continue as 2. (Not implemented yet)
+
+Note: A user will be queried only if the server requires it for ``HTTP`` or
+``HTTPS``, other protocols always require a user.
+
+In any case, if the server refuses the authentication, bzr reports to the user
+and terminates.
+
+Implementation constraints
+--------------------------
+
+* bzr should be able to prompt for a ``user`` for a given (``scheme``, ``host``
+ [, ``realm``]). Note that ``realm`` is available only after a first
+ connection attempt to the server.
+
+* No assumptions should be made about the clients of this service
+ (i.e. Transport is the primary target but plugins must be able to use it as
+ well, the definitions used: (``scheme, host, [port,] path``) are general
+ enough to described credentials for ``svn`` servers or LaunchPad XML-RPC
+ calls).
+
+* Policies regarding default users may be taken into account by the
+ implementations, there is no good way to represent that in this specification
+ and stays flexible enough to accommodate various needs (default user policies
+ may differ for different schemes and that may be easier to handle in the code
+ than in the authentication file itself).
+
+* If no user can be found by the mechanism described above, bzr should still
+ default to ``getpass.get_user()`` and may attempt a second matching to obtain
+ a password.
+
+* As this specification proposes a matching between some credentials
+ definitions and real URLs, the implementation provides an optional UI
+ feedback about which credential definition is used. Using ``-Dauth`` will
+ output some traces in the ``.bzr.log`` file metionning the sections
+ used. This allows the user to validate his definitions.
+
+Questions and Answers
+---------------------
+
+ * What if a ``.authinfo`` file exists ?
+
+ * It will be ignored,
+
+ * Automatic (one-time) conversions may be proposed if sufficient demand
+ exists,
+
+ * What if a ``.netrc`` file exists ?
+
+ * It is honored if the definition specifies
+ ``password_encoding=netrc``.
+
+ * What mode should the authentication file use ?
+
+ * 600 read/write for owner only by default, if another mode (more
+ permissive) is used, a warning will be issued to inform the users of the
+ potential risks.(Not implemented yet)
+
+ * What about using ``seahorse`` on Ubuntu or ``KeyChain Access`` on Mac OS X ?
+
+ * plugins can be written and registered to handle the associated
+ ``password_encoding``.
+
+ * Could it be possible to encode the whole authentication file with an SSH key
+ ?
+
+ * yes and if the user configure a ssh-agent it will not be queried for
+ pass-phrase every time we want to query the file for a password. But
+ that seems a bit extreme for a first version.(Not implemented yet and
+ may be never)
+
+ * Why can't bzr update the authentication file when it queried the user for a
+ password ?
+
+ * a future version may address that but:
+
+ 1. The user may want to decide which passwords are stored in the file and
+ which aren't.
+
+ 2. The user should decide if the passwords are encoded (and how) or not
+ (but we may default to base64).
+
+ 3. The right definition may be hard to get right, but reducing it to
+ (``scheme, host, [port,] user, password``) may be a good start. I.e. no
+ path so that all paths on the host will match. The user will have to
+ modify it for more complex configurations anyway.
+
diff --git a/doc/developers/btree_index_prefetch.txt b/doc/developers/btree_index_prefetch.txt
new file mode 100644
index 0000000..5ec1571
--- /dev/null
+++ b/doc/developers/btree_index_prefetch.txt
@@ -0,0 +1,294 @@
+====================
+BTree Index Prefetch
+====================
+
+This document outlines how we decide to pre-read extra nodes in the btree
+index.
+
+
+Rationale
+=========
+
+Because of the latency involved in making a request, it is often better to make
+fewer large requests, rather than more small requests, even if some of the
+extra data will be wasted.
+
+Example
+-------
+
+Using my connection as an example, I have a max bandwidth of 160kB/s, and a
+latency of between 100-400ms to London, I'll use 200ms for this example. With
+this connection, in 200ms you can download 32kB. So if you make 10 requests for
+4kB of data, you spend 10*.2s = 2s sending the requests, and 4*10/160 = .25s
+actually downloading the data. If, instead, you made 3 requests for 32kB of
+data each, you would take 3*.2s = .6s for requests, and 32*3/160 = .6s for
+downloading the data. So you save 2.25 - 1.2 = 1.05s even though you downloaded
+32*3-4*10 = 56kB of data that you probably don't need. On the other hand, if
+you made 1 request for 480kB, you would take .2s for the request, and
+480/160=3s for the data. So you end up taking 3.2s, because of the wasted
+440kB.
+
+
+BTree Structure
+===============
+
+This is meant to give a basic feeling for how the btree index is laid out on
+disk, not give a rigorous discussion. For that look elsewhere[ref?].
+
+The basic structure is that we have pages of 4kB. Each page is either a leaf,
+which holds the final information we are interested in, or is an internal node,
+which contains a list of references to the next layer of nodes. The layers are
+structured such that all nodes for the top layer come first, then the nodes for
+the next layer, linearly in the file.
+
+
+Example 1 layer
+---------------
+
+In the simplest example, all the data fits into a single page, the root node.
+This means the root node is a leaf node.
+
+
+Example 2 layer
+---------------
+
+As soon as the data cannot fit in a single node, we create a new internal node,
+make that the root, and start to create multiple leaf nodes. The root node then
+contains the keys which divide the leaf pages. (So if leaf node 1 ends with
+'foo' and leaf node 2 starts with 'foz', the root node would hold the key 'foz'
+at position 0).
+
+
+Example 3 layer
+---------------
+
+It is possible for enough leaf nodes to be created, that we cannot fit all
+there references in a single node. In this case, we again split, creating
+another layer, and setting that as the root. This layer then references the
+intermediate layer, which references the final leaf nodes.
+
+In all cases, the root node is a single page wide. The next layer can have 2-N
+nodes.
+
+
+Current Info
+------------
+
+Empirically, we've found that the number of references that can be stored on a
+page varies from about 60 to about 180, depending on how much we compress, and
+how similar the keys are. Internal nodes also achieve approximately the same
+compression, though they seem to be closer to 80-100 and not as variable. For
+most of this discussion, we will assume each page holds 100 entries, as that
+makes the math nice and clean.
+
+So the idea is that if you have <100 keys, they will probably all fit on the
+root page. If you have 100 - 10,000 keys, we will have a 2-layer structure, if
+you have 10,000 - 1,000,000 keys, you will have a 3-layer structure. 10^6-10^8
+will be 4-layer, etc.
+
+
+Data and Request
+================
+
+It is important to be aware of what sort of data requests will be made on these
+indexes, so that we know how to optimize them. This is still a work in
+progress, but generally we are searching through ancestry. The final
+information (in the leaf nodes) is stored in sorted order. Revision ids are
+generally of the form "prefix:committer@email-timestamp-randomtail".
+This means that revisions made by the same person around the same time will be
+clustered, but revisions made by different people at the same time will not be
+clustered.
+For files, the keys are ``(file-id, revision-id)`` tuples. And file-ids are
+generally ``basename-timestamp-random-count`` (depending on the converter).
+This means that all revisions for a given file-id will be grouped together, and
+that files with similar names will be grouped together. However, files
+committed in the same revisions will not be grouped together in the index.[1]_
+
+.. [1] One interesting possibility would be to change file-ids from being
+ 'basename-...', to being 'containing-dirname-filename-...', which would
+ group files in the similarly named directories together.
+
+
+In general, we always start with a request for the root node of the index, as
+it tells us the final structure of the rest of the index. How many total pages,
+what pages are internal nodes and what layer, which ones are leaves. Before
+this point, we do know the *size* of the index, because that is stored in the
+``pack-names`` file.
+
+
+Thoughts on expansion
+=====================
+
+This is just a bullet list of things to consider when expanding a request.
+
+* We generally assume locality of reference. So if we are currently reading
+ page 10, we are more likely to read page 9 or 11 than we are page 20.
+
+* However, locality of reference only really holds within a layer. If we are
+ reading the last node in a layer, we are unlikely to read the first node of
+ the next layer. In fact, we are most likely to read the *last* node of the
+ next layer.
+
+ More directly, we are probably equally likely to read any of the nodes in the
+ next layer, which could be referred to by this layer. So if we have a
+ structure of 1 root node, 100 intermediate nodes, and 10,000 leaf nodes.
+ They will have offsets: 0, 1-101, 102-10,102.
+
+ If we read the root node, we are likely to want any of the 1-101 nodes
+ (because we don't know where the key points). If we are reading node 90, then
+ we are likely to want a node somewhere around 9,100-9,200.
+
+* When expanding a request, we are considering that we probably want to read on
+ the order of 10 pages extra. (64kB / 4kB = 16 pages.) It is unlikely that we
+ want to expand the requests by 100.
+
+* At the moment, we assume that we don't have an idea of where in the next
+ layer the keys might fall. We *could* use a predictive algorithm assuming
+ homogenous distribution. When reading the root node, we could assume an even
+ distribution from 'a-z', so that a key starting with 'a' would tend to fall
+ in the first few pages of the next layer, while a key starting with 'z' would
+ fall at the end of the next layer.
+ However, this is quite likely to fail in many ways. Specific examples:
+
+ * Converters tend to use an identical prefix. So all revisions will start
+ with 'xxx:', leading us to think that the keys fall in the last half,
+ when in reality they fall evenly distributed.
+
+ * When looking in text indexes. In the short term, changes tend to be
+ clustered around a small set of files. Short term changes are unlikely to
+ cross many pages, but it is unclear what happens in the mid-term.
+ Obviously in the long term, changes have happened to all files.
+
+ A possibility, would be to use this after reading the root node. And then
+ using an algorithm that compares the keys before and after this record, to
+ find what a distribution would be, and estimate the next pages.
+
+ This is a lot of work for a potentially small benefit, though.
+
+* When checking for N keys, we do sequential lookups in each layer. So we look
+ at layer 1 for all N keys, then in layer 2 for all N keys, etc. So our
+ requests will be clustered by layer.
+
+* For projects with large history, we are probably more likely to end up with a
+ bi-modal distribution of pack files. Where we have 1 pack file with a large
+ index, and then several pack files with small indexes, several with tiny
+ indexes, but no pack files with medium sized indexes.
+ This is because a command like ``bzr pack`` will combine everything into a
+ single large file. Commands like ``bzr commit`` will create an index with a
+ single new record, though these will be packaged together by autopack.
+ Commands like ``bzr push`` and ``bzr pull`` will create indexes with more
+ records, but these are unlikely to be a significant portion of the history.
+ Consider bzr has 20,000 revisions, a single push/pull is likely to only be
+ 100-200 revisions, or 1% of the history.
+
+ Note that there will always be cases where things are evenly distributed, but
+ we probably shouldn't *optimize* for that case.
+
+* 64kB is 16 pages. 16 pages is approximately 1,600 keys.
+
+* We are considering an index with 1 million keys to be very large. 10M is
+ probably possible, and maybe 100M, but something like 1 billion keys is
+ unlikely. So a 3-layer index is fairly common (it exists already in bzr), but
+ a 4-layer is going to be quite rare, and we will probably never see a
+ 5-layer.
+
+* There are times when the second layer is going to be incompletely filled out.
+ Consider an index with 101 keys. We found that we couldn't fit everything
+ into a single page, so we expanded the btree into a root page and a leaf
+ page, and started a new leaf page. However, the root node only has a single
+ entry. There are 3 pages, but only one of them is "full".
+ This happens again when we get near the 10,000 node barrier. We found we
+ couldn't fit the index in a single page, so we split it into a higher layer,
+ and 1 more sub-layer. So we have 1 root node, 2 layer-2 nodes, and N leaf
+ nodes (layer 3). If we read the first 3 nodes, we will have read all internal
+ nodes.
+
+ It is certainly possible to detect this for the first-split case (when things
+ no-longer fit into just the root node), as there will only be a few nodes
+ total. Is it possible to detect this from only the 'size' information for the
+ second-split case (when the index no longer fits in a single page, but still
+ fits in only a small handful of pages)?
+
+ This only really works for the root + layer 2. For layers 3+ they will always
+ be too big to read all at once. However, until we've read the root, we don't
+ know the layout, so all we have to go on is the size of the index, though
+ that also gives us the explicit total number of pages.
+ So it doesn't help to read the root page and then decide. However, on the
+ flip side, if we read *before* the split, then we don't gain much, as we are
+ reading pages we aren't likely to be interested in.
+
+ For example:
+
+ We have 100 keys, which fits onto 100 pages, with a single root node. At
+ 1,100 keys, it would be 101 leaf pages, which would then cause us to need 2
+ index pages, triggering an extra layer. However, this is very sensitive to
+ the number of keys we fit per-page, which depends on the compression.
+ Although, we could consider 2,000 keys. Which would be 200 leaf nodes, and
+ 2 intermediate nodes, and a single root node. It is unlikely that we would
+ ever be able to fit 200 references into a single root node.
+
+ So if we pretend that we split at 1 page, 100 pages, and 10,000 pages. We
+ might be able to say, at 1-5 pages, read all pages, for 5-100 pages, read
+ only the root. At 100 - 500 pages, read 1-5 pages, for 500-10,000 read only
+ the root. At 10,000-50,000 read 1-5 pages again, but above 50,000 read only
+ the root. We could bias this a bit smaller, say at powers of 80, instead of
+ powers of 100, etc. The basic idea is that if we are *close* to a layer
+ split, go ahead and read a small number of extra pages.
+
+* The previous discussion applies whenever we have an upper layer that is not
+ completely full. So the pages referenced by the last node from the upper
+ layer will often not have a full 100-way fan out. Probably not worthwhile
+ very often, though.
+
+* Sometimes we will be making a very small request for a very small number of
+ keys, we don't really want to bloat tiny requests. Hopefully we can find a
+ decent heuristic to determine when we will be wanting extra nodes later,
+ versus when we expect to find all we want right now.
+
+
+Algorithm
+=========
+
+This is the basic outline of the algorithm.
+
+1. If we don't know the size of the index, don't expand as we don't know what
+ is available. (This only really applies to the pack-names file, which is
+ unlikely to ever become larger than 1 page anyway.)
+
+2. If a request is already wide enough to be greater than the number of
+ recommended pages, don't bother trying to expand. This only really happens
+ with LocalTransport which recommends a single page.
+
+3. Determine what pages have already been read (if any). If the pages left to
+ read can fit in a single request, just request them. This tends to happen on
+ medium sized indexes (ones with low hundreds of revisions), and near the end
+ when we've read most of the whole index already.
+
+4. If we haven't read the root node yet, and we can't fit the whole index into
+ a single request, only read the root node. We don't know where the layer
+ boundaries are anyway.
+
+5. If we haven't read "tree depth" pages yet, and are only requesting a single
+ new page don't expand. This is meant to handle the 'lookup 1 item in the
+ index' case. In a large pack file, you'll read only a single page at each
+ layer and then be done. When spidering out in a search, this will cause us
+ to take a little bit longer to start expanding, but once we've started we'll
+ be expanding at full velocity. This could be improved by having indexes
+ inform each other that they have already entered the 'search' phase, or by
+ having a hint from above to indicate the same.
+
+ However, remember the 'bi-modal' distribution. Most indexes will either be
+ very small, or very large. So either we'll read the whole thing quickly, or
+ we'll end up spending a lot of time in the index. Which makes a small number
+ of extra round trips to large indexes a small overhead. For 2-layer nodes,
+ this only 'wastes' one round trip.
+
+6. Now we are ready to expand the requests. Expand by looking for more pages
+ next to the ones requested that fit within the current layer. If you run
+ into a cached page, or a layer boundary, search further only in the opposite
+ direction. This gives us proper locality of reference, and also helps
+ because when a search goes in a single direction, we will continue to
+ prefetch pages in that direction.
+
+..
+ vim: ft=rst tw=79 ai
diff --git a/doc/developers/bug-handling.txt b/doc/developers/bug-handling.txt
new file mode 100644
index 0000000..8841d0e
--- /dev/null
+++ b/doc/developers/bug-handling.txt
@@ -0,0 +1,330 @@
+***********************
+Tracking Bugs in Bazaar
+***********************
+
+This document describes the bug-tracking processes for developing Bazaar
+itself. Bugs in Bazaar are recorded in Launchpad.
+
+
+See also:
+
+* `Bazaar Developer Documents <index.html>`_.
+
+* `The Bazaar Development Cycle <cycle.html>`_.
+
+* `The Bazaar User Guide <../en/user-guide/index.html>`_ -- for
+ information on integrating Bazaar with other bug trackers.
+
+
+Links
+*****
+
+* `bzr bugs home page <https://bugs.launchpad.net/bzr>`_.
+
+* `Critical bugs <https://bugs.launchpad.net/bzr/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed>`_.
+
+* `Open bugs by importance <https://bugs.launchpad.net/bzr/+bugs>`_.
+
+* `Open bugs most recently changed first
+ <https://bugs.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-date_last_updated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=>`_.
+
+* `Most commonly duplicated bugs <http://tinyurl.com/bzr-bugs-by-dupes>`_.
+
+
+Generalities
+************
+
+Anyone involved with Bazaar is welcome to contribute to managing our bug
+reports. **Edit boldly**: try to help users out, assess importance or improve
+the bug description or status. Other people will see the bugs: it's
+better to have 20 of them processed and later change the status of a
+couple than to leave them lie.
+
+When you file a bug as a Bazaar developer or active user, if you feel
+confident in doing so, make an assessment of status and importance at the
+time you file it, rather than leaving it for someone else. It's more
+efficient to change the importance if someone else feels it's higher or
+lower, than to have someone else edit all bugs.
+
+It's more useful to actually ship bug fixes than to garden the bug
+database. It's more useful to take one bug through to a shipped fix than
+to partially investigate ten bugs. You don't get credit for a bug until
+the fix is shipped in a release. Users like getting a response to their
+report, but they generally care more about getting bugs fixed.
+
+The aim of investigating bugs before starting concentrated work on them is
+therefore only to:
+
+* determine if they are critical or high priority (and
+ should displace existing work)
+
+* garden sufficiently to keep the database usable: meaningful summaries,
+ and duplicates removed
+
+It's OK to fix some bugs that just annoy you, even if they're not
+rationally high.
+
+You can use ``--fixes lp:12345678`` when committing to associate the
+commit with a particular bug.
+
+If there are multiple bugs with related fixes, putting "[master]" in the
+title of one of them helps find it
+
+It's often fastest to find bugs just using the regular Google search
+engine, rather than Launchpad's search.
+
+Martin Pitt says:
+
+ | One of the things you should not do often is to start asking
+ | questions/for more debug info and then forget about the bug. It's just
+ | a waste of the reporter's and your time, and will create frustration
+ | on the reporter side.
+
+
+Priorities
+**********
+
+The suggested priorities for bug work are:
+
+1. Fix critical bugs.
+
+2. Get existing fixes through review and landed.
+
+3. Fix bugs that are already in progress.
+
+4. Look at bugs already assigned to you, and either start them, or change
+ your mind and unassign them.
+
+5. Take new bugs from the top of the stack.
+
+6. Triage new bugs.
+
+It's not strict and of course there is personal discretion but our work
+should be biased to the top of this hierarchy.
+
+
+Clear Bugs
+**********
+
+Bugs should have clear edges, so that you can make a clear statement about
+whether a bug is fixed or not. (Sometimes reality is complicated, but aim
+for each bug to be clear.)
+
+Bugs on documentation, performance, or UI are fine as long as they're
+clear bugs.
+
+Examples of good bugs:
+
+* "ValueError in frob_foo when committing changed symlink" - although
+ there may be many possible things that could cause a ValueError there,
+ you should at least know when you've fixed the problem described in this
+ bug.
+
+* "Unclear message about incompatible repositories" - even though the user
+ may not agree the new message is sufficiently clear, at least you know
+ when you've tried to fix it.
+
+Examples of bad bugs:
+
+* "Commit is too slow" - how fast is fast enough to close it? "Commit
+ reads the working tree twice" is clearer.
+
+
+Bug Status
+**********
+
+New
+ The bug has just been filed and hasn't been examined by a developer
+ yet.
+Incomplete
+ The bug requires more information from the reporter to make progress.
+
+ Only set this state if it's impossible or uneconomical to make
+ progress on the bug without that information. The bug will expire if
+ it remains in this state for two months.
+Confirmed
+ The bug report has been seen by a developer and we agree it's a bug.
+ You don't have to reproduce the bug to mark it Confirmed. (Generally
+ it's not a good idea for a developer to spend time reproducing the bug
+ until they're going to work on it.)
+Triaged
+ We don't use this status. If it is set, it means the same as
+ Confirmed.
+In Progress
+ Someone has started working on this. We can deliver the value of the
+ work already done by finishing and shipping the fix.
+
+ The bug keeps this state from the time someone does non-trivial
+ analysis, until the fix is merged to a release or trunk branch (when
+ it is Fix Released), or until they give up on it (back to New or
+ Confirmed) or decide it is Invalid or Incomplete.
+Won't Fix
+ The behaviour complained about is intentional and we won't fix it.
+ Needless to say, be thoughtful before using this status, and consider if
+ the user experience can be improved in some other way.
+Invalid
+ The reporter was confused, and this is not actually a bug.
+ Again, be sensitive in explaining this to the user.
+Fix Committed
+ Don't use this. If set on old bug, it probably means In Progress,
+ with the fix waiting for review. See Launchpad `bug 163694`_.
+Fix Released
+ The fix for this bug is now in the bzr branch that this task is for.
+ The branch for the default task on a bug is bzr.dev.
+
+ We use this value even though the fix may not have been been included
+ in a release yet because all the developer activity around it is
+ complete and we want to both avoid bug spam when releases happen, and
+ keep the list of bugs that developers see when they look at the bug
+ tracker trimmed to those that require action.
+
+ When setting a bug task to fix released, the bug target milestone
+ should be set to the release the fix will be included in (or was
+ included in, if you are updating an old bug). Don't spend too much
+ time updating this if you don't immediately know: its not critical
+ that it be set.
+
+.. _`bug 163694`: https://bugs.launchpad.net/launchpad/+bug/163694
+
+
+Bug Importance
+**************
+
+Critical
+ This is a serious bug that could cause data loss, stop bzr being
+ usable in an important case, or represents a regression in something
+ previously working. We should fix critical bugs before doing other
+ work, or seriously consider whether the bug is really critical
+ or whether the other change is more urgent.
+High
+ This is a bug that can seriously interfere with people's use of
+ Bazaar. We should seriously consider fixing these bugs before
+ working on new features.
+Medium
+ A regular bug. We'd like to fix them, but there may be a long delay.
+Low
+ Something suboptimal that may affect an unimportant case or have a
+ fairly easy workaround.
+Wishlist
+ These will basically never get done.
+
+Bugs rated Medium or lower are unlikely to get fixed unless they either
+pique the interest of a developer or are escalated due eg to many users
+being affected.
+
+Not every existing bug is correctly rated according to this scale, and we
+don't always follow this process, but we'd like to do it more. But
+remember, fixing bugs is more helpful than gardening them.
+
+
+Assignment
+**********
+
+Assigning a bug to yourself, or someone else, indicates a real intention
+to work on that bug soon.
+
+
+Targetting Bugs
+***************
+
+It's possible to target a bug to a milestone, eg
+<https://bugs.launchpad.net/bzr/+milestone/1.16>. We use this to help the
+release manager know what **must** be merged to make the release.
+
+Therefore, we don't target bugs that we'd like to have fixed or that could
+be fixed in a particular release, we only target bugs that must be fixed
+and that will cause us to slip the release if they're not fixed. At any time,
+very few if any of the bugs targeted to a release should be still open. By
+definition, these bugs should normally be Critical priority.
+
+
+Backports
+*********
+
+Sometimes we'll want to make a special point-release update (eg 1.15.1)
+off an already-released branch including a fix for a particular bug. To
+represent this, create a new bug task (ie link in the status table on the
+bug page) by clicking the `poorly-named
+<https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link.
+Target it to the appropriate series (ie 1.15). If the bug should also
+prevent any point releases of that series then you should also target the
+new task to the appropriate milestone within that release. (See Targeting Bugs
+above)
+
+This bug task then has a separate status and importance to indicate the
+separate work to get it into that release.
+
+
+Release Notes
+*************
+
+Most bugs that are fixed should be mentioned in the `Release Notes
+<../en/release-notes/>`_ for the forthcoming version,
+including the bug number.
+(Exceptions might be bugs that are not at all user visible.)
+
+
+Tags
+****
+
+Here are some bug tags we use. In Launchpad Bugs tags are currently of limited use, so don't feel obliged to tag bugs unless you're finding it useful.
+
+
+authentication
+ authenticating to servers
+
+backport
+ candidate for backporting to an update of the previous release
+
+dirstate
+ WorkingTree4
+
+easy
+ should be possible to finish in an hour or two
+
+hpss
+ bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
+
+hpssvfs
+ bugs for causes of VFS methods of the smart server
+
+launchpad
+ bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
+
+locale
+ problems using locales other than English
+
+memory
+ problems where we use too much memory for some reason
+
+newformat
+ fixing this would need a new disk format
+
+performance
+ bugs about performance problems.
+
+regression
+ bugs which represent an aspect of bzr becoming accidentally less good than it was.
+
+test
+ needs changes to the test framework
+
+transport
+ virtual filesystem for HTTP, SFTP, etc.
+
+trivial
+ should be very easy to fix (10-20 minutes) and easily landed: typically
+ just spelling errors and the like
+
+ui
+ bugs relating to the bzr user interface, e.g. confusing error messages.
+
+win32
+ bugs that mainly affects Windows. Also there is cygwin and win98 tags for
+ marking specific bugs.
+
+You can see the full list of tags in use at
+<https://bugs.launchpad.net/bzr/+bugs>. As of September 2008 the
+list is on the right.
+
+.. vim: ft=rst
diff --git a/doc/developers/bundle-creation.txt b/doc/developers/bundle-creation.txt
new file mode 100644
index 0000000..d311cfd
--- /dev/null
+++ b/doc/developers/bundle-creation.txt
@@ -0,0 +1,37 @@
+Bundle Creation
+===============
+1. Find common ancestor [O(a)] **O(b)**
+2. Emit bundle [O(a)] **O(b) O(h)**
+
+ Per revision
+
+ 1. emit metadata O(1)
+ 2. emit changes for files
+
+ 1. find changed files [O(c)] **O(f)**
+ 2. emit file metadata O(d)
+ 3. emit diff [O(e * e) * O(f) + O(h)] **O(i)**
+ 4. base64 encode O(g)
+
+3. **emit overal diff (or maybe do interdiff) O(e * e) * O(f)**
+
+:a: nodes in revision graph
+:b: number of descendants of common ancestor
+:c: number of files in the tree
+:d: length of metadata
+:e: number of lines
+:f: number of modified files
+:g: length of diff
+:h: nodes in knit graph of modified files
+:i: length of stored diff
+
+Needs
+-----
+- Improved common ancestor algorithm
+- Access to partial revision graph proportional to relevant revisions
+- Access to changed files proportional to number of change files and
+ intervening revisions
+- Use knit deltas without recomputing
+- Access to knit deltas in O(1) time
+- Access to snapshots in O(1) amortized time
+- All snapshots must have knit deltas
diff --git a/doc/developers/bundle-format4.txt b/doc/developers/bundle-format4.txt
new file mode 100644
index 0000000..0af1489
--- /dev/null
+++ b/doc/developers/bundle-format4.txt
@@ -0,0 +1,272 @@
+============================================
+Merge Directive format 2 and Bundle format 4
+============================================
+
+:Date: 2007-06-21
+
+Motivation
+----------
+Merge Directive format 2 represents a request to perform a certain merge. It
+provides access to all the data necessary to perform that merge, by including
+a branch URL or a bundle payload. It typically will include a preview of
+what applying the patch would do.
+
+Bundle Format 4 is designed to be a compact format for storing revision
+metadata that can be generated quickly and installed into a repository
+efficiently. It is not intended to be human-readable.
+
+Note
+----
+These two formats, taken together, can be viewed as the successor of Bundle
+format 0.9, so their specifications are combined. It is expected that in the
+future, bundle and merge-directive formats will vary independently.
+
+
+Bundle Format Name
+------------------
+This is the fourth bundle format to see public use. Previous versions were
+0.7, 0.8, and 0.9. Only 0.7's version number was aligned with a Bazaar
+release.
+
+
+Dependencies
+------------
+- Container format 1
+- Multiparent diffs
+- Bencode
+- Patch-RIO
+
+
+Description
+-----------
+Merge Directives fulfil the role previous bundle formats had of requesting a
+merge to be performed, but are a more flexible way of doing so. With the
+introduction of these two formats, there is a clear split between "directive",
+which is a request to merge (and therefore signable), and "bundle", which is
+just data.
+
+Merge Directive format 2 may provide a patch preview of the change being
+requested. If a preview is supplied, the receiving client will verify that
+the actual change matches the preview.
+
+Merge Directive format 2 also includes a testament hash, to ensure that if a
+branch is used, the branch cannot be subverted to cause the wrong changes to be
+applied.
+
+Bundle format 4 is designed to trade human-readability for speed and
+compactness. It does not contain a human-readable "prelude" patch.
+
+Merge Directive 2 Contents
+--------------------------
+This format consists of three sections, in the following order.
+
+
+Patch-RIO command section
+~~~~~~~~~~~~~~~~~~~~~~~~~
+This section is identical to the corresponding section in Format 1 merge
+directives, except as noted below. It is mandatory. It is terminated by a
+line reading ``#`` that is not preceeded by a line ending with ``\``.
+
+In order to support cherry-picking and patch comparison, this format adds a new
+piece of information, the ``base_revision_id``. This is a suggested base
+revision for merging. It may be supplied by the user. If not, it is
+calculated using the standard merge base algorithm, with the ``revision_id``
+and target branch's ``last_revision`` as its inputs.
+
+When merging, clients should use the ``base_revision_id`` when it is not
+already present in the ancestry of the ``last_revision`` of the target branch.
+If it is already present, clients should calculate a merge base in the normal
+way.
+
+
+Patch preview section
+~~~~~~~~~~~~~~~~~~~~~
+This section is optional. It begins with the line ``# Begin patch``. It is
+terminated by the end-of-file or by the beginning of a bundle section.
+
+Its contents are a unified diff, as per the ``bzr diff`` command. The FROM
+revision is the ``base_revision_id`` specified in the Patch-RIO section.
+
+
+Bundle section
+~~~~~~~~~~~~~~
+This section is optional, but if it is not supplied, a source_branch must be
+supplied. It begins with the line ``# Begin bundle``, and is terminated by the
+end-of-file.
+
+The contents are a base-64 encoded bundle. This may be any bundle format, but
+formats 4+ are strongly recommended. The base revision is the newest revision
+in the source branch which is an ancestor of all revisions not present in
+target which are ancestors of revision_id.
+
+This base revision may or may not be the same as the ``base_revision_id``. In
+particular, the ``base_revision_id`` may specify a cherry-pick, but all the
+ancestors of the ``base_revision_id`` should be installed in the target
+repository before performing such a merge.
+
+
+Bundle 4 Contents
+-----------------
+Bazaar revision bundles begin with a format marker that reads
+``# Bazaar revision bundle v4`` in plaintext. The remainder of the file is a
+``Bazaar pack format 1`` container. The container is compressed using bzip2.
+
+Putting the format marker in plaintext ensures that old clients will give good
+diagnostics, but renders the file unreadable by standard bzip2 utilities.
+
+Serialization
+~~~~~~~~~~~~~
+Format 4 records revision and inventory records in their repository
+serialization format. This minimizes translation and compression costs
+in the common case, where the sender and receiver use the same serialization
+format for their repository. Steps have been taken to ensure a faithful
+conversion when serialization formats are mismatched.
+
+
+Bundle Records
+~~~~~~~~~~~~~~
+The bundle format creates a single bundle-level record out of two container
+records. The first container record contains metainfo as a Bencoded dict. The
+second container record contains the body.
+
+The bundle record name is associated with the metainfo record. The body record
+is anonymous.
+
+
+Record metainfo
+~~~~~~~~~~~~~~~
+
+:record_kind: The storage strategy of the record. May be ``fulltext`` (the
+ record body contains the full text of the value), ``mpdiff`` (the record
+ body contains a multi-parent diff of the value), or ``header`` (no record
+ body).
+:parents: Used in fulltext and mpdiff records. The revisions that should be
+ noted as parents of this revision in the repository. For mpdiffs, this is
+ also the list of build-parents.
+:sha1: Used in mpdiff records. The sha-1 hash of the full-text value.
+
+
+Bundle record naming
+~~~~~~~~~~~~~~~~~~~~~
+All bundle records have a single name, which is associated with the metainfo
+container record. Records are named according to the body's content-kind,
+revision-id, and file-id.
+
+Content-kind may be one of:
+
+:file: a version of a user file
+:inventory: the tree inventory
+:revision: the revision metadata for a revision
+:signature: the revision signature for a revision
+
+Names are constructed like so: ``content-kind/revision-id/file-id``. Values
+are iterpreted left-to-right, so if two values are present, they are
+content-kind and revision-id.
+A record has a file-id if-and-only-if it is a file record.
+Info records have no revision or file-id.
+Inventory, revision and signature all have content-kind and revision-id, but
+no file-id.
+
+Layout
+~~~~~~
+The first record is an info/header record.
+
+The subsequent records are mpdiff file records. The are ordered first by file
+id, then in topological order by revision-id.
+
+The next records are mpdiff inventory records. They are topologically sorted.
+
+The next records are revision and signature fulltexts. They are interleaved
+and topologically sorted.
+
+Info record
+~~~~~~~~~~~
+The info record has type ``header``. It has no revision_id or file_id.
+Its metadata contains:
+
+:serializer: A string describing the serialization format used for inventory
+ and revision data. May be ``xml5``, ``xml6`` or ``xml7``.
+:supports_rich_root: 1 if the source repository supports rich roots,
+ 0 otherwise.
+
+
+Implementation notes
+~~~~~~~~~~~~~~~~~~~~
+- knit deltas contain almost enough information to extract the original
+ SequenceMatcher.get_matching_blocks() call used to produce them. Combining
+ that information with the relevant fulltexts allows us to avoid performing
+ sequence matching on any fulltexts for which we have deltas.
+
+- MultiParent deltas contain ``get_matching_blocks`` output almost verbatim,
+ but if there is more than one parent, the information about the leftmost
+ parent may be incomplete. However, for single-parent multiparent diffs, we
+ can extract the ``SequenceMatcher.get_matching_blocks`` output, and therefore
+ ``the SequenceMatcher.get_opcodes`` output used to create knit deltas.
+
+
+Installing data across serialization mismatches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In practice, there cannot be revision serialization mismatches, because the
+serialization of revisions has been consistent in serializations 5-7
+
+If there is a mismatch in inventory serialization formats, the receiver can
+
+ 1. extract the inventory objects for the parents
+ 2. serialize them using the bundle serialize
+ 3. apply the mpdiff
+ 4. calculate the fulltext sha1
+ 5. compare the calculated sha1 to the expected sha1
+ 6. deserialize using the bundle serializer
+ 7. serialize using the repository serializer
+ 8. add to the repository
+
+This is much slower, of course. But since the since the fulltext is verified
+at step 5, it should be just as safe as any other conversion.
+
+Model differences
+~~~~~~~~~~~~~~~~~
+
+Note that there may be model differences requiring additional changes. These
+differences are described by the "supports_rich_root" value in the info record.
+
+A subset of xml6 and xml7 records are compatible with xml5 (i.e. those that
+were converted from xml5 originally).
+
+When installing from a bundle whose serializer supports tree references to a
+repository that does not support tree references, clients should halt if they
+encounter a record containing a tree reference.
+
+When installing from a supports_rich_root bundle to a repository that does not
+support rich roots, clients should halt if they encounter an inventory record
+whose root directory revision-id does not match the inventory revision id.
+
+When installing from a bundle that does not support rich roots to a repository
+that does, additional knits should be added for the root directory, with a
+revision for each inventory revision.
+
+Validating preview patches
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+When applying a merge directive that includes a preview, clients should
+verify that the preview matches the changes requested by the merge directive.
+
+In order to do this, the client should generate a diff from the
+``base_revision_id`` to the ``revision_id``. This diff should be compared
+against the preview patch, making allowances for the fact that whitespace
+munging may have occurred.
+
+One form of whitespace munging that has been observed is line-ending
+conversion. Certain mail clients such as Evolution do not respect the
+line-endings of text attachments. Since line-ending conversion is unlikely to
+alter the meaning of a patch, it seems safe to ignore line endings when
+comparing the preview patch.
+
+Another form of whitespace munging that has been observed is
+trailing-whitespace stripping. Again, it seems unlikely that stripping
+trailing whitespace could alter the meaning of a patch. Such a distinction
+is also invisible to readers, so ignoring it does not create a new threat. So
+it seems reasonable to ignore trailing whitespace when comparing the patches.
+
+Other mungings are possible, but it is recommended not to implement support
+for them until they have been observed. Each of these changes makes the
+comparison more approximate, and the more approximate it becomes, the easier it
+is to provide a preview patch that does not match the requested changes.
diff --git a/doc/developers/bundles.txt b/doc/developers/bundles.txt
new file mode 100644
index 0000000..5ae5c62
--- /dev/null
+++ b/doc/developers/bundles.txt
@@ -0,0 +1,85 @@
+=======
+Bundles
+=======
+
+Status
+======
+
+:Date: 2007-06-19
+
+This document describes the current and future design of the bzr bundle facility.
+
+.. contents::
+
+Motivation
+==========
+
+Bundles are intended to be a compact binary representation of the changes done within
+a branch for transmission between users. Bundles should be able to be used
+easily and seamlessly - we want to avoid having a parallel set of commands to
+get data from within a bundle.
+
+A related concept is **merge directives** which are used to transmit bzr merge
+and merge-like operations from one user to another in such a way that the
+recipient can be sure they get the correct data the initiator desired.
+
+Desired features
+================
+
+* A bundle should be able to substitute for the entire branch in any bzr
+ command that operates on branches in a read only fashion.
+* Bundles should be as small as possible without losing data to keep them
+ feasible for including in emails.
+
+Historical Design
+=================
+
+Not formally documented, the current released implementation can be found
+in bzrlib.bundle.serializer. One key element is that this design included
+parts of the branch data as human readable diffs; which were then subject
+to corruption by transports such as email.
+
+June 2007 Design
+================
+`Bundle Format 4 spec`_
+
+.. _Bundle Format 4 spec: bundle-format4.html
+
+
+Future Plans
+============
+
+Bundles will be implemented as a 'Shallow Branch' with the branch and
+repository data combined into a single file. This removes the need to
+special case bundle handling for all command which read from branches.
+
+Physical encoding
+-----------------
+
+Bundles will be encoded using the bzr pack format. Within the pack the
+branch metadata will be serialised as a BzrMetaDir1 branch entry. The
+Repository data added by the revisions contained in the bundle will be
+encoded using multi parent diffs as they are the most pithy diffs we are
+able to create today in the presence of merges. XXX More details needed?
+
+Code reuse
+----------
+
+Ideally we can reuse our BzrMetaDir based branch formats directly within a
+Bundle by layering a Transport interface on top of the pack - or just
+copying the data out into a readonly memory transport when we read the
+pack. This suggests we will have a pack specific Control instance,
+replacing the usual 'BzrDir' instance, but use the Branch class as-is.
+
+For the Repository access, we will create a composite Repository using the
+planned Repository Stacking API, and a minimal Repository implementation
+that can work with the multi parent diffs within the bundle.
+
+We will need access to a branch that has the basis revision of the bundle
+to be able to construct revisions from within it - this is a requirement
+for Shallow Branches too, so hopefully we can define a single mechanism at
+the Branch level to gain access to that.
+
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/case-insensitive-file-systems.txt b/doc/developers/case-insensitive-file-systems.txt
new file mode 100644
index 0000000..0d8b7b4
--- /dev/null
+++ b/doc/developers/case-insensitive-file-systems.txt
@@ -0,0 +1,97 @@
+Case Insensitive File Systems
+=============================
+
+Bazaar must be portable across operating-systems and file-systems. While the
+primary file-system for an operating-system might have some particular
+characteristics, it's not necessary that *all* file-systems for that
+operating-system will have the same characteristics.
+
+For example, the FAT32 file-system is most commonly found on Windows operating
+systems, and has the characteristics usually associated with a Windows
+file-system. However, USB devices means FAT32 file-systems are often used
+with GNU/Linux systems, so the current operating system doesn't necessarily reflect the
+capabilities of the file-system.
+
+Bazaar supports 3 kinds of file-systems, each to different degrees.
+
+* Case-sensitive file-systems: This is the file-system generally used on
+ GNU/Linux: 2 files can differ only by case, and the exact case must be used
+ when opening a file.
+
+* Case-insensitive, case-preserving (cicp) file-systems: This is the
+ file-system generally used on Windows; FAT32 is an example of such a
+ file-system. Although existing files can be opened using any case, the
+ exact case used to create the file is preserved and available for programs
+ to query. Two files that differ only by case is not allowed.
+
+* Case-insensitive: This is the file-system used by very old Windows versions
+ and is rarely encountered "in the wild". Two files that differ only by
+ case is not allowed and the case used to create a file is not preserved.
+
+As can be implied by the above descriptions, only the first two are considered
+relevant to a modern Bazaar.
+
+For more details, including use cases, please see
+http://wiki.bazaar.canonical.com/CasePreservingWorkingTreeUseCases
+
+Handling these file-systems
+---------------------------
+
+The fundamental problem handling these file-systems is that the user may
+specify a file name or inventory item with an "incorrect" case - where
+"incorrect" simply means different than what is stored - from the user's
+point-of-view, the filename is still correct, as it can be used to open, edit
+delete etc the item.
+
+The approach Bazaar takes is to "fixup" each of the command-line arguments
+which refer to a filename or an inventory item - where "fixup" means to
+adjust the case specified by the user so it exactly matches an existing item.
+
+There are two places this match can be performed against - the file-system
+and the Bazaar inventory. When looking at a case-insensitive file-system, it
+is impossible to have 2 names that differ only by case, so there is no
+ambiguity. The inventory doesn't have the same rules, but it is expected that
+projects which wish to work with Windows would, by convention, avoid filenames
+that differ only by case.
+
+The rules for such fixups turn out to be quite simple:
+
+* If an argument refers to an existing inventory item, we fixup the argument
+ using the inventory. This is, basically, all commands that take a filename
+ or directory argument *other* than 'add' and in some cases 'mv'
+
+* If an argument refers to an existing filename for the creation of an
+ inventory item (eg, add), then the case of the existing file on the disk
+ will be used. However, Bazaar must still check the inventory to prevent
+ accidentally creating 2 inventory items that differ only by case.
+
+* If an argument results in the creation of a *new* filename (eg, a move
+ destination), the argument will be used as specified. Bzr will create
+ a file and inventory item that exactly matches the case specified (although
+ as above, care must be taken to avoid creating two inventory items that
+ differ only by case.)
+
+Implementation of support for these file-systems
+------------------------------------------------
+
+From the description above, it can be seen the implementation is fairly
+simple and need not intrude on the internals of Bazaar too much; most of
+the time it is simply converting a string specified by the user to the
+"canonical" form as stored in either the inventory or filesystem. These
+boil down to the following new API functions:
+
+* osutils.canonical_relpath() - like osutils.relpath() but adjust the case
+ of the result to match any existing items.
+
+* Tree.get_canonical_inventory_path - somewhat like Tree.get_symlink_target(),
+ Tree.get_file() etc; returns a name with the case adjusted to match
+ existing inventory items.
+
+* osutils.canonical_relpaths() and Tree.get_canonical_inventory_paths() - like
+ the 'singular' versions above, but accept and return sequences and therefore
+ offer more optimization opportunities when working with multiple names.
+
+The only complication is the requirement that Bazaar not allow the creation
+of items that differ only by case on such file-systems. For this requirement,
+case-insensitive and cicp file-systems can be treated the same. The
+'case_sensitive' attribute on a MutableTree is used to control this behaviour.
diff --git a/doc/developers/check.txt b/doc/developers/check.txt
new file mode 100644
index 0000000..ad8fe4e
--- /dev/null
+++ b/doc/developers/check.txt
@@ -0,0 +1,63 @@
+Check Notes
+===========
+
+.. contents:: :local:
+
+Overview
+--------
+
+Check has multiple responsibilities:
+
+* Ensure that the data as recorded on disk is accessible intact and unaltered.
+* Ensure that a branch/repository/tree/whatever is ready for upgrade.
+* Look for and report on recorded-data issues where previous bzr's, or changing
+ situations have lead so some form of inconsistency.
+* Report sufficient information for a user to either fix the issue themselves
+ or report a bug that will hopefully be sufficiently detailed we can fix based
+ on the initial report.
+* Not scare users when run if everything is okey-dokey.
+
+Ideally one check invocation can do all these things.
+
+Repository
+----------
+
+Things that can go wrong:
+* Bit errors or alterations may occur in raw data.
+* Data that is referenced may be missing
+* There could be a lot of garbage in upload etc.
+* File graphs may be inconsistent with inventories and parents.
+* The revision graph cache can be inconsistent with the revision data.
+
+Branch
+------
+
+Things that can go wrong:
+* Tag or tip revision ids may be missing from the repo.
+* The revno tip cache may be wrong.
+* Various URLS could be problematic (not inaccessible, just invalid)
+* Stacked-on branch could be inaccessible.
+
+Tree
+----
+
+Things that can go wrong:
+* Bit errors in dirstate.
+* Corrupt or invalid shelves.
+* Corrupt dirstates written to disk.
+* Cached inventories might not match repository.
+
+Duplicate work
+--------------
+
+If we check every branch in a repo separately we will encounter duplicate
+effort in assessing things like missing tags/tips, revno cache etc.
+
+Outline of approach
+-------------------
+
+To check a repository, we scan for branches, open their trees and generate
+summary data. We then collect all the summary data in as compact a form as
+possible and do a detailed check on the repository, calling back out to branch
+and trees as we encounter the actual data that that tree/branch requires to
+perform its check.
diff --git a/doc/developers/code-review.txt b/doc/developers/code-review.txt
new file mode 100644
index 0000000..125a337
--- /dev/null
+++ b/doc/developers/code-review.txt
@@ -0,0 +1,104 @@
+Reviewing proposed changes to Bazaar
+####################################
+
+All non-trivial code changes coming in to Bazaar are reviewed by someone else.
+
+Anyone is welcome to review any patch. You don't need to have a full
+understanding of the codebase to find problems in the code, the documentation,
+or the concept of the patch.
+
+Normally changes by core contributors are reviewed by one other core
+developer, and changes from other people are reviewed by two core
+developers. Use intelligent discretion about whether the patch is trivial.
+
+No one likes their merge requests sitting in a queue going nowhere: this
+is pure waste. We prioritize reviewing existing proposals.
+Canonical dedicates some staff time to providing prompt helpful reviews.
+(See <http://wiki.bazaar.canonical.com/PatchPilot/>.)
+
+From late 2009 on, we do all our code reviews through Launchpad's
+merge proposal interface.
+
+
+Reviewing proposed changes
+==========================
+
+There are three main requirements for code to get in:
+
+* Doesn't reduce test coverage: if it adds new methods or commands,
+ there should be tests for them. There is a good test framework
+ and plenty of examples to crib from, but if you are having trouble
+ working out how to test something feel free to post a draft patch
+ and ask for help.
+
+* Doesn't reduce design clarity, such as by entangling objects
+ we're trying to separate. This is mostly something the more
+ experienced reviewers need to help check.
+
+* Improves bugs, features, speed, or code simplicity.
+
+Code that goes in should not degrade any of these aspects. Patches are
+welcome that only cleanup the code without changing the external
+behaviour. The core developers take care to keep the code quality high
+and understandable while recognising that perfect is sometimes the enemy
+of good.
+
+It is easy for reviews to make people notice other things which should be
+fixed but those things should not hold up the original fix being accepted.
+New things can easily be recorded in the bug tracker instead.
+
+It's normally much easier to review several smaller patches than one large
+one. You might want to use ``bzr-loom`` to maintain threads of related
+work, or submit a preparatory patch that will make your "real" change
+easier.
+
+
+Checklist for reviewers
+=======================
+
+* Do you understand what the code's doing and why?
+
+* Will it perform reasonably for large inputs, both in memory size and
+ run time? Are there some scenarios where performance should be
+ measured?
+
+* Is it tested, and are the tests at the right level? Are there both
+ blackbox (command-line level) and API-oriented tests?
+
+* If this change will be visible to end users or API users, is it
+ appropriately documented in release notes and/or in whats-new ?
+
+* Does it meet the `coding standards <code-style.html>`_?
+
+* If it changes the user-visible behaviour, does it update the help
+ strings and user documentation?
+
+* If it adds a new major concept or standard practice, does it update the
+ developer documentation?
+
+* (your ideas here...)
+
+
+Reviews on Launchpad
+====================
+
+Anyone can propose or comment on a merge proposal just by creating a
+Launchpad account.
+
+From <https://code.launchpad.net/bzr/+activereviews> you can see all
+currently active reviews, and choose one to comment on. This page also
+shows proposals that are now approved and should be merged by someone with
+PQM access.
+
+<https://help.launchpad.net/Code/Review> explains the various merge proposal
+states. Note that we don't use state *Approved* until the patch is completely
+ready to merge.
+
+
+Landing approved changes
+========================
+
+Once a merge proposal is approved and finished, it's sent to PQM (the patch
+queue manager) which will automatically test and integrate it. The recommended
+way to start this off is by running the ``feed-pqm`` script from
+<https://launchpad.net/hydrazine/>.
diff --git a/doc/developers/code-style.txt b/doc/developers/code-style.txt
new file mode 100644
index 0000000..3a1d156
--- /dev/null
+++ b/doc/developers/code-style.txt
@@ -0,0 +1,518 @@
+***********************
+Bazaar Code Style Guide
+***********************
+
+Code layout
+===========
+
+Please write PEP-8__ compliant code.
+
+__ http://www.python.org/peps/pep-0008.html
+
+One often-missed requirement is that the first line of docstrings
+should be a self-contained one-sentence summary.
+
+We use 4 space indents for blocks, and never use tab characters. (In vim,
+``set expandtab``.)
+
+Trailing white space should be avoided, but is allowed.
+You should however not make lots of unrelated white space changes.
+
+Unix style newlines (LF) are used.
+
+Each file must have a newline at the end of it.
+
+Lines should be no more than 79 characters if at all possible.
+Lines that continue a long statement may be indented in either of
+two ways:
+
+within the parenthesis or other character that opens the block, e.g.::
+
+ my_long_method(arg1,
+ arg2,
+ arg3)
+
+or indented by four spaces::
+
+ my_long_method(arg1,
+ arg2,
+ arg3)
+
+The first is considered clearer by some people; however it can be a bit
+harder to maintain (e.g. when the method name changes), and it does not
+work well if the relevant parenthesis is already far to the right. Avoid
+this::
+
+ self.legbone.kneebone.shinbone.toebone.shake_it(one,
+ two,
+ three)
+
+but rather ::
+
+ self.legbone.kneebone.shinbone.toebone.shake_it(one,
+ two,
+ three)
+
+or ::
+
+ self.legbone.kneebone.shinbone.toebone.shake_it(
+ one, two, three)
+
+For long lists, we like to add a trailing comma and put the closing
+character on the following line. This makes it easier to add new items in
+future::
+
+ from bzrlib.goo import (
+ jam,
+ jelly,
+ marmalade,
+ )
+
+There should be spaces between function parameters, but not between the
+keyword name and the value::
+
+ call(1, 3, cheese=quark)
+
+
+Python versions
+===============
+
+Bazaar supports Python from 2.4 through 2.6, and in the future we want to
+support Python 2.7 and 3.0. Avoid using language features added in 2.5,
+2.6 or 2.7, or features deprecated in Python 3.0. (You can check v3
+compatibility using the ``-3`` option of Python2.6.)
+
+Specifically:
+
+* Don't use the ``with`` statement.
+
+* Don't ``from . import``.
+
+* Don't use ``try/except/finally``, which is not supported in Python2.4,
+ use separate nested ``try/except`` and ``try/finally`` blocks.
+
+
+hasattr and getattr
+===================
+
+``hasattr`` should not be used because it swallows exceptions including
+``KeyboardInterrupt``. Instead, say something like ::
+
+ if getattr(thing, 'name', None) is None
+
+
+kwargs
+======
+
+``**kwargs`` in the prototype of a function should be used sparingly.
+It can be good on higher-order functions that decorate other functions,
+such as ``addCleanup`` or ``assertRaises``, or on functions that take only
+(or almost only) kwargs, where any kwargs can be passed.
+
+Otherwise, be careful: if the parameters to a function are a bit complex
+and might vary over time (e.g. the ``commit`` API) then we prefer to pass an
+object rather than a bag of positional and/or keyword args. If you have
+an arbitrary set of keys and values that are different with each use (e.g.
+string interpolation inputs) then again that should not be mixed in with
+the regular positional/keyword args, it seems like a different category of
+thing.
+
+
+Imitating standard objects
+==========================
+
+Don't provide methods that imitate built-in classes (eg ``__in__``,
+``__call__``, ``__int__``, ``__getitem__``) unless the class you're
+implementing really does act like the builtin class, in semantics and
+performance.
+
+For example, old code lets you say ``file_id in inv`` but we no longer
+consider this good style. Instead, say more explicitly
+``inv.has_id(file_id)``.
+
+``__repr__``, ``__cmp__``, ``__str__`` are usually fine.
+
+
+Module Imports
+==============
+
+* Imports should be done at the top-level of the file, unless there is
+ a strong reason to have them lazily loaded when a particular
+ function runs. Import statements have a cost, so try to make sure
+ they don't run inside hot functions.
+
+* Module names should always be given fully-qualified,
+ i.e. ``bzrlib.hashcache`` not just ``hashcache``.
+
+
+Naming
+======
+
+Functions, methods or members that are relatively private are given
+a leading underscore prefix. Names without a leading underscore are
+public not just across modules but to programmers using bzrlib as an
+API.
+
+We prefer class names to be concatenated capital words (``TestCase``)
+and variables, methods and functions to be lowercase words joined by
+underscores (``revision_id``, ``get_revision``).
+
+For the purposes of naming some names are treated as single compound
+words: "filename", "revno".
+
+Consider naming classes as nouns and functions/methods as verbs.
+
+Try to avoid using abbreviations in names, because there can be
+inconsistency if other people use the full name.
+
+
+Standard Names
+==============
+
+``revision_id`` not ``rev_id`` or ``revid``
+
+Functions that transform one thing to another should be named ``x_to_y``
+(not ``x2y`` as occurs in some old code.)
+
+
+Destructors
+===========
+
+Python destructors (``__del__``) work differently to those of other
+languages. In particular, bear in mind that destructors may be called
+immediately when the object apparently becomes unreferenced, or at some
+later time, or possibly never at all. Therefore we have restrictions on
+what can be done inside them.
+
+0. If you think you need to use a ``__del__`` method ask another
+ developer for alternatives. If you do need to use one, explain
+ why in a comment.
+
+1. Never rely on a ``__del__`` method running. If there is code that
+ must run, instead have a ``finally`` block or an ``addCleanup`` call an
+ explicit ``close`` method.
+
+2. Never ``import`` from inside a ``__del__`` method, or you may crash the
+ interpreter!!
+
+3. Prior to bzr 2.4, we sometimes used to raise warnings from del methods
+ that the object was not cleaned up or closed. We no longer do this:
+ failure to close the object doesn't cause a test failure; the warning
+ appears an arbitrary long time after the problem occurred (the object
+ being leaked); merely having a del method inhibits Python gc; the
+ warnings appear to users and upset them; they can also break tests that
+ are checking what appears on stderr.
+
+In short, just don't use ``__del__``.
+
+Cleanup methods
+===============
+
+Often when something has failed later code will fail too, including
+cleanups invoked from ``finally`` blocks. These secondary failures are
+generally uninteresting compared to the original exception. ``bzrlib``
+has some facilities you can use to mitigate this.
+
+* In ``Command`` subclasses, prefer the ``add_cleanup`` method to using
+ ``try``/``finally`` blocks. E.g. to acquire a lock and ensure it will
+ always be released when the command is done::
+
+ self.add_cleanup(branch.lock_read().unlock)
+
+ This also avoids heavily indented code. It also makes it easier to notice
+ mismatched lock/unlock pairs (and other kinds of resource
+ acquire/release) because there isn't a large block of code separating
+ them.
+
+* Use the ``only_raises`` decorator (from ``bzrlib.decorators``) when
+ defining methods that are typically called in ``finally`` blocks, such
+ as ``unlock`` methods. For example, ``@only_raises(LockNotHeld,
+ LockBroken)``. All errors that are unlikely to be a knock-on failure
+ from a previous failure should be allowed.
+
+* Consider using the ``OperationWithCleanups`` helper from
+ ``bzrlib.cleanup`` anywhere else you have a ``finally`` block that
+ might fail.
+
+
+Factories
+=========
+
+In some places we have variables which point to callables that construct
+new instances. That is to say, they can be used a lot like class objects,
+but they shouldn't be *named* like classes. Things called ``FooBar`` should
+create an instance of ``FooBar``. A factory method that might create a
+``FooBar`` or might make something else should be called ``foo_factory``.
+
+
+Registries
+==========
+
+Several places in Bazaar use (or will use) a registry, which is a
+mapping from names to objects or classes. The registry allows for
+loading in registered code only when it's needed, and keeping
+associated information such as a help string or description.
+
+
+InterObject and multiple dispatch
+=================================
+
+The ``InterObject`` provides for two-way `multiple dispatch`__: matching
+up for example a source and destination repository to find the right way
+to transfer data between them.
+
+.. __: http://en.wikipedia.org/wiki/Multiple_dispatch
+
+There is a subclass ``InterObject`` classes for each type of object that is
+dispatched this way, e.g. ``InterRepository``. Calling ``.get()`` on this
+class will return an ``InterObject`` instance providing the best match for
+those parameters, and this instance then has methods for operations
+between the objects.
+
+::
+
+ inter = InterRepository.get(source_repo, target_repo)
+ inter.fetch(revision_id)
+
+``InterRepository`` also acts as a registry-like object for its
+subclasses, and they can be added through ``.register_optimizer``. The
+right one to run is selected by asking each class, in reverse order of
+registration, whether it ``.is_compatible`` with the relevant objects.
+
+Lazy Imports
+============
+
+To make startup time faster, we use the ``bzrlib.lazy_import`` module to
+delay importing modules until they are actually used. ``lazy_import`` uses
+the same syntax as regular python imports. So to import a few modules in a
+lazy fashion do::
+
+ from bzrlib.lazy_import import lazy_import
+ lazy_import(globals(), """
+ import os
+ import subprocess
+ import sys
+ import time
+
+ from bzrlib import (
+ errors,
+ transport,
+ revision as _mod_revision,
+ )
+ import bzrlib.transport
+ import bzrlib.xml5
+ """)
+
+At this point, all of these exist as a ``ImportReplacer`` object, ready to
+be imported once a member is accessed. Also, when importing a module into
+the local namespace, which is likely to clash with variable names, it is
+recommended to prefix it as ``_mod_<module>``. This makes it clearer that
+the variable is a module, and these object should be hidden anyway, since
+they shouldn't be imported into other namespaces.
+
+While it is possible for ``lazy_import()`` to import members of a module
+when using the ``from module import member`` syntax, it is recommended to
+only use that syntax to load sub modules ``from module import submodule``.
+This is because variables and classes can frequently be used without
+needing a sub-member for example::
+
+ lazy_import(globals(), """
+ from module import MyClass
+ """)
+
+ def test(x):
+ return isinstance(x, MyClass)
+
+This will incorrectly fail, because ``MyClass`` is a ``ImportReplacer``
+object, rather than the real class.
+
+It also is incorrect to assign ``ImportReplacer`` objects to other variables.
+Because the replacer only knows about the original name, it is unable to
+replace other variables. The ``ImportReplacer`` class will raise an
+``IllegalUseOfScopeReplacer`` exception if it can figure out that this
+happened. But it requires accessing a member more than once from the new
+variable, so some bugs are not detected right away.
+
+
+The Null revision
+=================
+
+The null revision is the ancestor of all revisions. Its revno is 0, its
+revision-id is ``null:``, and its tree is the empty tree. When referring
+to the null revision, please use ``bzrlib.revision.NULL_REVISION``. Old
+code sometimes uses ``None`` for the null revision, but this practice is
+being phased out.
+
+
+Object string representations
+=============================
+
+Python prints objects using their ``__repr__`` method when they are
+written to logs, exception tracebacks, or the debugger. We want
+objects to have useful representations to help in determining what went
+wrong.
+
+If you add a new class you should generally add a ``__repr__`` method
+unless there is an adequate method in a parent class. There should be a
+test for the repr.
+
+Representations should typically look like Python constructor syntax, but
+they don't need to include every value in the object and they don't need
+to be able to actually execute. They're to be read by humans, not
+machines. Don't hardcode the classname in the format, so that we get the
+correct value if the method is inherited by a subclass. If you're
+printing attributes of the object, including strings, you should normally
+use ``%r`` syntax (to call their repr in turn).
+
+Try to avoid the representation becoming more than one or two lines long.
+(But balance this against including useful information, and simplicity of
+implementation.)
+
+Because repr methods are often called when something has already gone
+wrong, they should be written somewhat more defensively than most code.
+They shouldn't have side effects like doing network or disk
+IO.
+The object may be half-initialized or in some other way in an illegal
+state. The repr method shouldn't raise an exception, or it may hide the
+(probably more useful) underlying exception.
+
+Example::
+
+ def __repr__(self):
+ return '%s(%r)' % (self.__class__.__name__,
+ self._transport)
+
+
+Exception handling
+==================
+
+A bare ``except`` statement will catch all exceptions, including ones that
+really should terminate the program such as ``MemoryError`` and
+``KeyboardInterrupt``. They should rarely be used unless the exception is
+later re-raised. Even then, think about whether catching just
+``Exception`` (which excludes system errors in Python2.5 and later) would
+be better.
+
+The ``__str__`` method on exceptions should be small and have no side
+effects, following the rules given for `Object string representations`_.
+In particular it should not do any network IO, or complicated
+introspection of other objects. All the state needed to present the
+exception to the user should be gathered before the error is raised.
+In other words, exceptions should basically be value objects.
+
+
+Test coverage
+=============
+
+All code should be exercised by the test suite. See the `Bazaar Testing
+Guide <http://doc.bazaar.canonical.com/developers/testing.html>`_ for detailed
+information about writing tests.
+
+
+Assertions
+==========
+
+Do not use the Python ``assert`` statement, either in tests or elsewhere.
+A source test checks that it is not used. It is ok to explicitly raise
+AssertionError.
+
+Rationale:
+
+* It makes the behaviour vary depending on whether bzr is run with -O
+ or not, therefore giving a chance for bugs that occur in one case or
+ the other, several of which have already occurred: assertions with
+ side effects, code which can't continue unless the assertion passes,
+ cases where we should give the user a proper message rather than an
+ assertion failure.
+* It's not that much shorter than an explicit if/raise.
+* It tends to lead to fuzzy thinking about whether the check is
+ actually needed or not, and whether it's an internal error or not
+* It tends to cause look-before-you-leap patterns.
+* It's unsafe if the check is needed to protect the integrity of the
+ user's data.
+* It tends to give poor messages since the developer can get by with
+ no explanatory text at all.
+* We can't rely on people always running with -O in normal use, so we
+ can't use it for tests that are actually expensive.
+* Expensive checks that help developers are better turned on from the
+ test suite or a -D flag.
+* If used instead of ``self.assert*()`` in tests it makes them falsely
+ pass with -O.
+
+emacs setup
+===========
+
+In emacs::
+
+ ;(defface my-invalid-face
+ ; '((t (:background "Red" :underline t)))
+ ; "Face used to highlight invalid constructs or other uglyties"
+ ; )
+
+ (defun my-python-mode-hook ()
+ ;; setup preferred indentation style.
+ (setq fill-column 79)
+ (setq indent-tabs-mode nil) ; no tabs, never, I will not repeat
+ ; (font-lock-add-keywords 'python-mode
+ ; '(("^\\s *\t" . 'my-invalid-face) ; Leading tabs
+ ; ("[ \t]+$" . 'my-invalid-face) ; Trailing spaces
+ ; ("^[ \t]+$" . 'my-invalid-face)); Spaces only
+ ; )
+ )
+
+ (add-hook 'python-mode-hook 'my-python-mode-hook)
+
+The lines beginning with ';' are comments. They can be activated
+if one want to have a strong notice of some tab/space usage
+violations.
+
+Portability Tips
+================
+
+The ``bzrlib.osutils`` module has many useful helper functions, including
+some more portable variants of functions in the standard library.
+
+In particular, don't use ``shutil.rmtree`` unless it's acceptable for it
+to fail on Windows if some files are readonly or still open elsewhere.
+Use ``bzrlib.osutils.rmtree`` instead.
+
+Using the ``open(..).read(..)`` or ``open(..).write(..)`` style chaining
+of methods for reading or writing file content relies on garbage collection
+to close the file which may keep the file open for an undefined period of
+time. This may break some follow up operations like rename on Windows.
+Use ``try/finally`` to explictly close the file. E.g.::
+
+ f = open('foo.txt', 'w')
+ try:
+ f.write(s)
+ finally:
+ f.close()
+
+
+Terminology
+===========
+
+Bazaar is a GNU project and uses standard GNU terminology, especially:
+
+ * Use the word "Linux" to refer to the Linux kernel, not as a synechoche
+ for the entire operating system. (See `bug 528253
+ <https://bugs.launchpad.net/bzr/+bug/528253>`_).
+
+ * Don't say "open source" when you mean "free software".
+
+
+Dynamic imports
+===============
+
+If you need to import a module (or attribute of a module) named in a
+variable:
+
+ * If importing a module, not an attribute, and the module is a top-level
+ module (i.e. has no dots in the name), then it's ok to use the builtin
+ ``__import__``, e.g. ``__import__(module_name)``.
+ * In all other cases, prefer ``bzrlib.pyutils.get_named_object`` to the
+ built-in ``__import__``. ``__import__`` has some subtleties and
+ unintuitive behaviours that make it hard to use correctly.
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/colocated-branches.txt b/doc/developers/colocated-branches.txt
new file mode 100644
index 0000000..78e31a4
--- /dev/null
+++ b/doc/developers/colocated-branches.txt
@@ -0,0 +1,129 @@
+co-located branches
+===================
+
+At the moment, each Bazaar branch has a separate directory in the file
+system. While this works well, and makes it very easy to discover
+branches there are several situations where it might be useful to also
+support multiple branches under the same file system directory.
+
+Rationale
+---------
+
+Allowing multiple branches to live under the same directory in the file
+system means that it is possible to very easily share the same working
+tree and repository between those branches, without having a lot of fs
+infrastructure.
+
+Git and Mercurial (can) store multiple branches under a single directory
+in the file system - per repository, so to speak. In order for this to
+be accessible in Bazaar, Bazaar needs to have the right APIs and UI for
+accessing these branches.
+
+Use Cases
+---------
+
+Carla has a large C-based project with a large tree and a lot of .o
+files that get generated as part of her build process. She doesn't want
+to create a new working tree for each new branch but simply uses "bzr
+switch" to switch between the different colocated branches that all use
+the same working tree.
+
+Brad has a single project with a lot of related branches. He works on
+them and occasionally pushes all of those branches to a remote host
+using a single push command.
+
+Joe follows one of his co-workers local branches in Mercurial by pulling
+into Bazaar.
+
+Implementation
+--------------
+
+UI Changes
+~~~~~~~~~~
+
+Bazaar URLs need to have some way to address colocated branches in
+directories that contain multiple branches.
+
+Per RFC3986 we have picked the comma (",") to allow the specification of
+colocated branch names. Comma's in path names would have to be
+urlencoded at first to avoid ambiguity, though perhaps it would be
+possible to support heuristics later when interpreting user-specified URLs.
+
+An example URL would be:
+
+ bzr://bazaar.launchpad.net/~jelmer/bzr/bzr.dev,colo-urls
+
+The segment after the comma will initially be interpreted as a colocated
+branch name but we would like to keep the option to allow
+key=value style specifications in the future and DWIM for segments that
+do not contain an =. Following the RFC the comma would be interpreted within
+the scope of a path segment. In other words, in the URL:
+
+ git://git.debian.org/pkg-python-debian/python-debian.git,unstable/README
+
+unstable is interpreted as the colocated branch living in the python-debian.git
+control directory; README is a path inside of the branch.
+
+Control directories will also have the notion of an "active" branch. This is
+the branch that is being used by a working tree, if present and the branch
+that will be used if no explicit colocated branch is specified. The
+active branch support makes it easier to deal with existing bzrdirs and
+is useful when accessing foreign control directories that have the concept
+as well.
+
+A new command 'bzr rmbranch' needs to be added to make it possible to
+remove colocated branches, as this won't be possible by simple
+directory removal, at least not of a user-visible directory.
+
+Code Changes
+~~~~~~~~~~~~
+
+BzrDirFormat will need a supports_colocated_branches property that
+indicates whether a format supports the creation, removal and accessing of
+colocated branches.
+
+Several methods on BzrDir will need to be updated to take an option branch_name
+parameter. If this parameter is not specified or None, the active branch
+will be used.
+
+The methods that will have to be extended are:
+
+ * BzrDir.open_branch()
+ * BzrDir.create_branch()
+ * BzrDir.destroy_branch()
+ * BzrDir.get_branch_transport()
+
+ * BranchFormat.initialise()
+ * BranchFormat.open()
+
+A new BzrDir.list_branches() method will return all colocated branches
+present in a control directory.
+
+Any URL interpreting methods (e.g. Branch.open) will need to be updated
+to extract a colocated branch name and need to pass that into the
+relevant methods.
+
+Existing callers of BzrDir.{create,open,destroy}_branch() need to
+be updated to pass in branch names and optionally be changed to use
+BzrDir.list_branches().
+
+Schema Changes
+--------------
+
+No format changes are necessary at first; at least, even if Bazaar
+provides the right infrastructure it doesn't have to support this
+feature in its own file formats.
+
+Eventually, Bazaar could easily support colocated branches by just
+creating a new branch transport for each colocated branch and have a
+"regular" branch live there. This would require something like
+BzrDirMeta2 though. An example of this is implemented in the
+lp:bzr-colocated plugin
+
+Further integration
+-------------------
+
+Loggerhead and Launchpad need to be updated to show colocated branches
+(perhaps in a similar way as they would show tags?).
+
+qbzr/bzr-gtk need to be updated to support colocated branches.
diff --git a/doc/developers/commit.txt b/doc/developers/commit.txt
new file mode 100644
index 0000000..4e8b75d
--- /dev/null
+++ b/doc/developers/commit.txt
@@ -0,0 +1,635 @@
+Commit Performance Notes
+========================
+
+.. contents:: :local:
+
+Changes to commit
+-----------------
+
+We want to improve the commit code in two phases.
+
+Phase one is to have a better separation from the format-specific logic,
+the user interface, and the general process of committing.
+
+Phase two is to have better interfaces by which a good workingtree format
+can efficiently pass data to a good storage format. If we get phase one
+right, it will be relatively easy and non-disruptive to bring this in.
+
+
+Commit: The Minimum Work Required
+---------------------------------
+
+Here is a description of the minimum work that commit must do. We
+want to make sure that our design doesn't cost too much more than this
+minimum. I am trying to do this without making too many assumptions
+about the underlying storage, but am assuming that the ui and basic
+architecture (wt, branch, repo) stays about the same.
+
+The basic purpose of commit is to:
+
+1. create and store a new revision based on the contents of the working tree
+2. make this the new basis revision for the working tree
+
+We can do a selected commit of only some files or subtrees.
+
+The best performance we could hope for is:
+- stat each versioned selected working file once
+- read from the workingtree and write into the repository any new file texts
+- in general, do work proportional to the size of the shape (eg
+inventory) of the old and new selected trees, and to the total size of
+the modified files
+
+In more detail:
+
+1.0 - Store new file texts: if a versioned file contains a new text
+there is no avoiding storing it. To determine which ones have changed
+we must go over the workingtree and at least stat each file. If the
+file is modified since it was last hashed, it must be read in.
+Ideally we would read it only once, and either notice that it has not
+changed, or store it at that point.
+
+On the other hand we want new code to be able to handle files that are
+larger than will fit in memory. We may then need to read each file up
+to two times: once to determine if there is a new text and calculate
+its hash, and again to store it.
+
+1.1 - Store a tree-shape description (ie inventory or similar.) This
+describes the non-file objects, and provides a reference from the
+Revision to the texts within it.
+
+1.2 - Generate and store a new revision object.
+
+1.3 - Do delta-compression on the stored objects. (git notably does
+not do this at commit time, deferring this entirely until later.)
+This requires finding the appropriate basis for each modified file: in
+the current scheme we get the file id, last-revision from the
+dirstate, look into the knit for that text, extract that text in
+total, generate a delta, then store that into the knit. Most delta
+operations are O(n**2) to O(n**3) in the size of the modified files.
+
+1.4 - Cache annotation information for the changes: at the moment this
+is done as part of the delta storage. There are some flaws in that
+approach, such as that it is not updated when ghosts are filled, and
+the annotation can't be re-run with new diff parameters.
+
+2.1 - Make the new revision the basis for the tree, and clear the list
+of parents. Strictly this is all that's logically necessary, unless
+the working tree format requires more work.
+
+The dirstate format does require more work, because it caches the
+parent tree data for each file within the working tree data. In
+practice this means that every commit rewrites the entire dirstate
+file - we could try to avoid rewriting the whole file but this may be
+difficult because variable-length data (the last-changed revision id)
+is inserted into many rows.
+
+The current dirstate design then seems to mean that any commit of a
+single file imposes a cost proportional to the size of the current
+workingtree. Maybe there are other benefits that outweigh this.
+Alternatively if it was fast enough for operations to always look at
+the original storage of the parent trees we could do without the
+cache.
+
+2.2 - Record the observed file hashes into the workingtree control
+files. For the files that we just committed, we have the information
+to store a valid hash cache entry: we know their stat information and
+the sha1 of the file contents. This is not strictly necessary to the
+speed of commit, but it will be useful later in avoiding reading those
+files, and the only cost of doing it now is writing it out.
+
+In fact there are some user interface niceties that complicate this:
+
+3 - Before starting the commit proper, we prompt for a commit message
+and in that commit message editor we show a list of the files that
+will be committed: basically the output of bzr status. This is
+basically the same as the list of changes we detect while storing the
+commit, but because the user will sometimes change the tree after
+opening the commit editor and expect the final state to be committed I
+think we do have to look for changes twice. Since it takes the user a
+while to enter a message this is not a big problem as long as both the
+status summary and the commit are individually fast.
+
+4 - As the commit proceeds (or after?) we show another status-like
+summary. Just printing the names of modified files as they're stored
+would be easy. Recording deleted and renamed files or directories is
+more work: this can only be done by reference to the primary parent
+tree and requires it be read in. Worse, reporting renames requires
+searching by id across the entire parent tree. Possibly full
+reporting should be a default-off verbose option because it does
+require more work beyond the commit itself.
+
+5 - Bazaar currently allows for missing files to be automatically
+marked as removed at the time of commit. Leaving aside the ui
+consequences, this means that we have to update the working inventory
+to mark these files as removed. Since as discussed above we always
+have to rewrite the dirstate on commit this is not substantial, though
+we should make sure we do this in one pass, not two. I have
+previously proposed to make this behaviour a non-default option.
+
+We may need to run hooks or generate signatures during commit, but
+they don't seem to have substantial performance consequences.
+
+If one wanted to optimize solely for the speed of commit I think
+hash-addressed file-per-text storage like in git (or bzr 0.1) is very
+good. Remarkably, it does not need to read the inventory for the
+previous revision. For each versioned file, we just need to get its
+hash, either by reading the file or validating its stat data. If that
+hash is not already in the repository, the file is just copied in and
+compressed. As directories are traversed, they're turned into texts
+and stored as well, and then finally the revision is too. This does
+depend on later doing some delta compression of these texts.
+
+Variations on this are possible. Rather than writing a single file
+into the repository for each text, we could fold them into a single
+collation or pack file. That would create a smaller number of files
+in the repository, but looking up a single text would require looking
+into their indexes rather than just asking the filesystem.
+
+Rather than using hashes we can use file-id/rev-id pairs as at
+present, which has several consequences pro and con.
+
+
+Commit vs Status
+----------------
+
+At first glance, commit simply stores the changes status reports. In fact,
+this isn't technically correct: commit considers some files modified that
+status does not. The notes below were put together by John Arbash Meinel
+and Aaron Bentley in May 2007 to explain the finer details of commit to
+Ian Clatworthy. They are recorded here as they are likely to be useful to
+others new to Bazaar ...
+
+1) **Unknown files have a different effect.** With --no-strict (the default)
+ they have no effect and can be completely ignored. With --strict they
+ should cause the commit to abort (so you don't forget to add the two new
+ test files that you just created).
+
+2) **Multiple parents.** 'status' always compares 2 trees, typically the
+ last-committed tree and the current working tree. 'commit' will compare
+ more trees if there has been a merge.
+
+ a) The "last modified" property for files.
+ A file may be marked as changed since the last commit, but that
+ change may have come in from the merge, and the change could have
+ happened several commits back. There are several edge cases to be
+ handled here, like if both branches modified the same file, or if
+ just one branch modified it.
+
+ b) The trickier case is when a file appears unmodified since last
+ commit, but it was modified versus one of the merged branches. I
+ believe there are a few ways this can happen, like if a merged
+ branch changes a file and then reverts it back (you still update
+ the 'last modified' field).
+ In general, if both sides disagree on the 'last-modified' flag,
+ then you need to generate a new entry pointing 'last-modified' at
+ this revision (because you are resolving the differences between
+ the 2 parents).
+
+3) **Automatic deletion of 'missing' files.** This is a point that we go
+ back and forth on. I think the basic idea is that 'bzr commit' by
+ default should abort if it finds a 'missing' file (in case that file was
+ renamed rather than deleted), but 'bzr commit --auto' can add unknown
+ files and remove missing files automatically.
+
+4) **sha1 for newly added files.** status doesn't really need this: it should
+ only care that the file is not present in base, but is present now. In
+ some ways commit doesn't care either, since it needs to read and sha the
+ file itself anyway.
+
+5) **Nested trees.** status doesn't recurse into nested trees, but commit does.
+ This is just because not all of the nested-trees work has been merged yet.
+
+ A tree-reference is considered modified if the subtree has been
+ committed since the last containing-tree commit. But commit needs to
+ recurse into every subtree, to ensure that a commit is done if the
+ subtree has changed since its last commit. _iter_changes only reports
+ on tree-references that are modified, so it can't be used for doing
+ subtree commits.
+
+
+Avoiding Work: Smarter Change Detection
+---------------------------------------
+
+Commit currently walks through every file building an inventory. Here is
+Aaron's brain dump on a better way ...
+
+_iter_changes won't tell us about tree references that haven't changed,
+even if those subtrees have changed. (Unless we ask for unchanged
+files, which we don't want to do, of course.)
+
+There is an iter_references method, but using it looks just as expensive
+as calling kind().
+
+I did some work on updating commit to use iter_changes, but found for
+multi-parent trees, I had to fall back to the slow inventory comparison
+approach.
+
+Really, I think we need a call akin to iter_changes that handles
+multiple parents, and knows to emit entries when InventoryEntry.revision
+is all that's changed.
+
+
+Avoiding Work: Better Layering
+------------------------------
+
+For each file, commit is currently doing more work than it should. Here is
+John's take on a better way ...
+
+Note that "_iter_changes" *does* have to touch every path on disk, but
+it just can do it in a more efficient manner. (It doesn't have to create
+an InventoryEntry for all the ones that haven't changed).
+
+I agree with Aaron that we need something a little different than
+_iter_changes. Both because of handling multiple parents, as well as we
+don't want it to actually read the files if we have a stat-cache miss.
+
+Specifically, the commit code *has* to read the files because it is
+going to add the text to the repository, and we want it to compute the
+sha1 at *that* time, so we are guaranteed to have the valid sha (rather
+than just whatever the last cached one was). So we want the code to
+return 'None' if it doesn't have an up-to-date sha1, rather than reading
+the file and computing it, just before it returns it to the parent.
+
+The commit code (0.16) should really be restructured. It's layering is
+pretty wrong.
+
+Specifically, calling "kind()" requires a stat of the file. But we have
+to do a stat to get the size/whether the record is up-to-date, etc. So
+we really need to have a "create_an_up_to_date_inventory()" function.
+But because we are accessing every object on disk, we want to be working
+in tuples rather than Inventory objects. And because DirState already
+has the parent records next to the current working inventory, it can do
+all the work to do really fast comparison and throw-away of unimportant
+records.
+
+The way I made "bzr status" fast is by moving the 'ignore this record'
+ability as deep into the stack as I could get. Status has the property
+that you don't care about most of the records, just like commit. So the
+sooner you can stop evaluating the 99% that you don't care about, the
+less work you do.
+
+
+Avoiding work: avoiding reading parent data
+-------------------------------------------
+
+We would like to avoid the work of reading any data about the parent
+revisions. We should at least try to avoid reading anything from the
+repository; we can also consider whether it is possible or useful to hold
+less parent information in the working tree.
+
+When a commit of selected files is requested, the committed snapshot is a
+composite of some directories from the parent revision and some from the
+working tree. In this case it is logically necessary to have the parent
+inventory information.
+
+If file last-change information or per-file graph information is stored
+then it must be available from the parent trees.
+
+If the Branch's storage method does delta compression at commit time it
+may need to retrieve file or inventory texts from the repository.
+
+It is desirable to avoid roundtrips to the Repository during commit,
+particularly because it may be remote. If the WorkingTree can determine
+by itself that a text was in the parent and therefore should be in the
+Repository that avoids one roundtrip per file.
+
+There is a possibility here that the parent revision is not stored, or not
+correctly stored, in the repository the tree is being committed into, and
+so the committed tree would not be reconstructable. We could check that
+the parent revision is present in the inventory and rely on the invariant
+that if a revision is present, everything to reconstruct it will be
+present too.
+
+
+Code structure
+--------------
+
+Caller starts a commit
+
+>>> Branch.commit(from_tree, options)
+
+This creates a CommitBuilder object matched to the Branch, Repository and
+Tree. It can vary depending on model differences or by knowledge of what
+is efficient with the Repository and Tree. Model differences might
+include whether no-text-change merges need to be reported, and whether the
+
+The basic CommitBuilder.commit structure can be
+
+1. Ask the branch if it is ready to commit (up to date with master if
+ any.)
+
+2. Ask the tree if it is ready to commit to the branch (up to date with
+ branch?), no conflicts, etc
+
+3. Commit changed files; prototype implementation:
+
+ a. Ask the working tree for all committable files; for each it should
+ return the per-file parents, stat information, kind, etc.
+
+ b. Ask the repository to store the new file text; the repository should
+ return the stored sha1 and new revision id.
+
+4. Commit changed inventory
+
+5. Commit revision object
+
+
+
+
+
+
+
+
+
+Complications of commit
+-----------------------
+
+Bazaar (as of 0.17) does not support selective-file commit of a merge;
+this could be done if we decide how it should be recorded - is this to be
+stored as an overall merge revision; as a preliminary non-merge revisions;
+or will the per-file graph diverge from the revision graph.
+
+There are several checks that may cause the commit to be refused, which
+may be activated or deactivated by options.
+
+* presence of conflicts in the tree
+
+* presence of unknown files
+
+* the working tree basis is up to date with the branch tip
+
+* the local branch is up to date with the master branch, if there
+ is one and --local is not specified
+
+* an empty commit message is given,
+
+* a hook flags an error
+
+* a "pointless" commit, with no inventory changes
+
+Most of these require walking the tree and can be easily done while
+recording the tree shape. This does require that it be possible to abort
+the commit after the tree changes have been recorded. It could be ok to
+either leave the unreachable partly-committed records in the repository,
+or to roll back.
+
+Other complications:
+
+* when automatically adding new files or deleting missing files during
+ commit, they must be noted during commit and written into the working
+ tree at some point
+
+* refuse "pointless" commits with no file changes - should be easy by
+ just refusing to do the final step of storing a new overall inventory
+ and revision object
+
+* heuristic detection of renames between add and delete (out of scope for
+ this change)
+
+* pushing changes to a master branch if any
+
+* running hooks, pre and post commit
+
+* prompting for a commit message if necessary, including a list of the
+ changes that have already been observed
+
+* if there are tree references and recursing into them is enabled, then
+ do so
+
+Commit needs to protect against duplicated file ids
+
+
+Updates that need to be made in the working tree, either on conclusion
+of commit or during the scan, include
+
+* Changes made to the tree shape, including automatic adds, renames or
+ deletes
+
+* For trees (eg dirstate) that cache parent inventories, the old parent
+ information must be removed and the new one inserted
+
+* The tree hashcache information should be updated to reflect the stat
+ value at which the file was the same as the committed version, and the
+ content hash it was observed to have. This needs to be done carefully to
+ prevent inconsistencies if the file is modified during or shortly after
+ the commit. Perhaps it would work to read the mtime of the file before we
+ read its text to commit.
+
+
+Interface stack
+---------------
+
+The commit api is invoked by the command interface, and copies information
+from the tree into the branch and its repository, possibly updating the
+WorkingTree afterwards.
+
+The command interface passes:
+
+* a commit message (from an option, if any),
+* or an indication that it should be read interactively from the ui object;
+* a list of files to commit
+* an option for a dry-run commit
+* verbose option, or callback to indicate
+* timestamp, timezone, committer, chosen revision id
+* config (for what?)
+* option for local-only commit on a bound branch
+* option for strict commits (fail if there are unknown or missing files)
+* option to allow "pointless" commits (with no tree changes)
+
+(This is rather a lot of options to pass individually and just for code tidyness maybe some of them should be combine into objects.)
+
+>>> Branch.commit(from_tree, message, files_to_commit, ...)
+
+There will be different implementations of this for different Branch
+classes, whether for foreign branches or Bazaar repositories using
+different storage methods.
+
+Most of the commit should occur during a single lockstep iteration across
+the workingtree and parent trees. The WorkingTree interface needs to
+provide methods that give commit all it needs. Some of these methods
+(such as answering the file's last change revision) may be deprecated in
+newer working trees and there we have a choice of either calculating the
+value from the data that is present, or refusing to support commit to
+newer repositories.
+
+For a dirstate tree the iteration of changes from the parent can easily be
+done within its own iter_changes.
+
+Dirstate inventories may be most easily updated in a single operation at
+the end; however it may be best to accumulate data as we proceed through
+the tree rather than revisiting it at the end.
+
+Showing a progress bar for commit may not be necessary if we report files
+as they are committed. Alternatively we could transiently show a progress
+bar for each directory that's scanned, even if no changes are observed.
+
+This needs to collect a list of added/changed/removed files, each of which
+must have its text stored (if any) and containing directory updated. This
+can be done by calling Tree._iter_changes on the source tree, asking for
+changes
+
+In the 0.17 model the commit operation needs to know the per-file parents
+and per-file last-changed revision.
+
+(In this and other operations we must avoid having multiple layers walk
+over the tree separately. For example, it is no good to have the Command
+layer walk the tree to generate a list of all file ids to commit, because
+the tree will also be walked later. The layers that do need to operate
+per-file should probably be bound together in a per-dirblock iterator,
+rather than each iterating independently.)
+
+Branch->Tree interface
+----------------------
+
+The Branch commit code needs to ask the Tree what should be committed, in
+terms of changes from the parent revisions. If the Tree holds all the
+necessary parent tree information itself it can do it single handed;
+otherwise it may need to ask the Repository for parent information.
+
+This should be a streaming interface, probably like iter_changes returning
+information per directory block.
+
+The interface should not return a block for directories that are
+recursively unchanged.
+
+The tree's idea of what is possibly changed may be more conservative than
+that of the branch. For example the tree may report on merges of files
+where the text is identical to the parents: this must be recorded for
+Bazaar branches that record per-file ancestry but is not necessary for all
+branches. If the tree is responsible for determining when directories
+have been recursively modified then it will report on all the parents of
+such files. There are several implementation options:
+
+1. Return all files and directories the branch might want to commit, even
+if the branch ends up taking no action on them.
+
+2. When starting the iteration, the branch can specify what type of change
+is considered interesting.
+
+Since these types of changes are probably (??) rare compared to files that
+are either completely unmodified or substantially modified, the first may
+be the best and simplest option.
+
+The branch needs to build an inventory to commit, which must include
+unchanged files within changed directories. This should be returned from
+the working tree too. Repositories that store per-directory inventories
+will want to build and store these from the lowest directories up.
+For 0.17 format repositories with an all-in-one inventory it may be
+easiest to accumulate inventory entries in arbitrary order into an
+in-memory Inventory and then serialize it.
+
+It ought to be possible to commit any Tree into a Branch, without
+requiring a WorkingTree; the commit code should cope if the tree is not
+interested in updating hashcache information or does not have a
+``last_revision``.
+
+
+Information from the tree to repository
+---------------------------------------
+
+The main things the tree needs to tell the Branch about are:
+
+* A file is modified from its parent revision (in text, permissions,
+ other), and so its text may need to be stored.
+
+ Files should also be reported if they have more than one unique parent
+ revision, for repositories that store per-file graphs or last-change
+ revisions. Perhaps this behaviour should be optional.
+
+ **XXX:** are renames/deletions reported here too?
+
+* The complete contents of a modified directory, so that its inventory
+ text may be stored. This should be done after all the contained files
+ and directories have been reported. If there are unmodified files,
+ or unselected files carried through from
+
+ XXX: Actually perhaps not grouped by directory, but rather grouped
+ appropriately for the shape of inventory storage in the repository.
+
+ In a zoomed-in checkout the workingtree may not have all the shape data
+ for the entire tree.
+
+* A file is missing -- could cause either automatic removal or an aborted
+ commit.
+
+* Any unknown files -- can cause automatic addition, abortion of a strict
+ commit, or just reporting.
+
+
+Information from the repository to the tree
+-------------------------------------------
+
+After the commit the tree needs to be updated to the new revision. Some
+information which was accumulated during the commit must be made available
+to the workingtree. It's probably reasonable to hold it all in memory and
+allow the workingtree to get it in whatever order it wants.
+
+* A list of modified entries, and for each one:
+
+ * The stat values observed when the file was first read.
+
+ * The hash of the committed file text.
+
+ * The file's last-change revision, if appropriate.
+
+ This should include any entries automatically added or removed.
+
+This might be construed as an enhanced version of ``set_parent_trees``.
+We can avoid a stat on each file by using the value that was observed when
+it was first read.
+
+
+
+Selective commit
+----------------
+
+For a partial commit the directory contents may need to contain a mix of
+entries from the working tree and parent trees. This code probably
+shouldn't live in a specific tree implementation; maybe there should be a
+general filter that selects paths from one tree into another?
+
+However, the tree walking code does probably need to know about selected
+paths to avoid examining unselected files or directories.
+
+We never refuse selective file commits (except of merges).
+
+
+
+Common commit code
+------------------
+
+What is common to all commit implementations, regardless of workingtree or
+repository format?
+
+* Prompting for a commit message?
+* Strictness/conflict checks?
+* Auto add/remove?
+
+How should this be separated?
+
+
+
+Order of traversal
+------------------
+
+For current and contemplated Bazaar storage formats, we can only finally
+commit a directory after its contained files and directories have been
+committed.
+
+The dirstate workingtree format naturally iterates by directory in order
+by path, yielding directories before their contents. This may also be the
+most efficient order in which to stat and read the files.
+
+One option would be to construe the interface as a visitor which reports
+when files are detected to be changed, and also when directories are
+finished.
+
+
+Open question: per-file graphs
+------------------------------
+
+**XXX:** If we want to retain explicitly stored per-file graphs, it would
+seem that we do need to record per-file parents. We have not yet finally
+settled that we do want to remove them or treat them as a cache. This api
+stack is still ok whether we do or not, but the internals of it may
+change.
diff --git a/doc/developers/conf.py b/doc/developers/conf.py
new file mode 100644
index 0000000..8ed08f7
--- /dev/null
+++ b/doc/developers/conf.py
@@ -0,0 +1,81 @@
+# -*- coding: utf-8 -*-
+#
+# Bazaar documentation build configuration file, created by
+# sphinx-quickstart on Tue Jul 21 17:04:52 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path = [os.path.abspath('../..')] + sys.path
+
+# Most of the configuration for Bazaar docs is defined here ...
+from bzrlib.doc_generate.conf import *
+
+
+## Configuration specific to this site ##
+
+# The locale code for this documentation set
+bzr_locale = 'en'
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+html_short_title = u"Developer Document Catalog (%s)" % (release,)
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {'index': 'index.html'}
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'bzr-developers'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+bzr_documents = [
+ ('HACKING', 'bzr-en-developer-guide', u'Bazaar Developer Guide',
+ u'Bazaar Developers', 'manual'),
+ ('testing', 'bzr-en-testing-guide', u'Bazaar Testing Guide',
+ u'Bazaar Developers', 'manual'),
+ ('overview', 'bzr-en-architecture-overview', u'Bazaar Architecture Overview',
+ u'Bazaar Developers', 'howto'),
+ ('integration', 'bzr-en-integration-guide', u'Bazaar Integration Guide',
+ u'Bazaar Developers', 'howto'),
+]
+
+latex_documents = [
+ (start, target+'.tex', title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+texinfo_documents = [
+ (start, target, title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+# List of documents that shouldn't be included in the build.
+# Note: Maybe some of them *ought* to be linked in somewhere?
+unused_docs = [
+ 'add',
+ 'annotate',
+ 'bundle-creation',
+ 'bundle-format4',
+ 'check',
+ 'commit',
+ 'diff',
+ 'directory-fingerprints',
+ 'gc',
+ 'index-plain',
+ 'incremental-push-pull',
+ 'initial-push-pull',
+ 'merge-scaling',
+ 'missing',
+ 'performance-roadmap-rationale',
+ 'performance-use-case-analysis',
+ 'planned-change-integration',
+ 'planned-performance-changes',
+ 'revert',
+ 'status',
+ 'uncommit',
+]
diff --git a/doc/developers/configuration.txt b/doc/developers/configuration.txt
new file mode 100644
index 0000000..a02f112
--- /dev/null
+++ b/doc/developers/configuration.txt
@@ -0,0 +1,366 @@
+Configuring Bazaar
+==================
+
+.. contents::
+ :depth: 2
+
+As a Bazaar developer there are a few things you need to know about
+configuration:
+
+* how to add a new option,
+
+* how add a new stack,
+
+* how add a new store.
+
+The first sections in this document summarize the steps needed when adding a
+new configuration item, the rest of the document gives more internal details
+on how this is implemented.
+
+Get an option value
+-------------------
+
+Options values are obtained with ``stack.get(option_name)`` where ``stack``
+is one of the daughter classes of ``config.Stack``, see their docstrings for
+a description of which sections are used from which stores.
+
+The value returned is of the type declared for that ``Option`` and if
+nothing is specifically declared you will get the default for that option.
+
+Add a new option
+----------------
+
+You add a new ``Option`` to the ``option_registry``, either inside
+``bzrlib/config.py`` or during initialization of your plugin (use
+``register_lazy`` in this case). New plugins should have systematic
+hierarchical names so that related values are grouped together::
+
+ option_registry.register(
+ Option('dirstate.fdatasync', default=True,
+ from_unicode=bool_from_store,
+ help="Flush dirstate changes onto physical disk? ...."))
+
+You then need to decide which stack is appropriate to implement the Option
+policy:
+
+* which config files (aka ``Store``) needs to be queried, which sections are
+ relevant and in what order,
+
+* which section will receive the modifications (if relevant).
+
+The docstrings for the existing stacks cover most of the known use cases.
+
+Modify an option value or delete an option
+------------------------------------------
+
+Just reading an option is what is needed most of the time, modifying option
+values or removing options is usually something that is not automated but
+left to the user (with ``bzr config``).
+
+Nevertheless, if you need to save a modified option value, use
+``.set(option_name, value)`` and ``.remove(option_name)`` to delete the
+option. Both methods are provided by the ``Stack`` object.
+
+But before doing that, you must be sure that the stack you're using have a
+writable section (this is true for ``GlobalStack`` which uses the
+``DEFAULT`` section in ``bazaar.conf`` and for ``BranchStack``which uses the
+no-name section in ``branch.conf``).
+
+Old and new configuration code
+------------------------------
+
+There is (as of late 2011) some older and some newer configuration code. The
+old code has specific methods for various checks or uses classes like
+``GlobalConfig``. Don't add to to it; try to remove it.
+
+If you encounter an option using the old code you may want to migrate
+it. This generally involves:
+
+* registering the option,
+
+* replace the old config by a stack:
+
+ * ``GlobalConfig`` became ``GlobalStack``,
+
+ * ``LocationConfig`` became ``LocationStack``,
+
+ * ``BranchConfig`` became ``BranchStack`` (or in this case,
+ ``get_config()`` became ``get_config_stack()``.
+
+* replace the custom accessor calls with ``conf.get(option_name)``.
+
+The new config code provides some help for commonly encountered use cases
+that can allow further simplifications like:
+
+* providing a default value when the option is not defined in any way by the
+ user,
+
+* convert the unicode string provided by the user into a suitable
+ representation (integer, list, etc).
+
+If you start migrating a given option to the config stacks, don't stop
+mid-way, all its uses should be covered (tests included). There are some
+edge cases where updates via one API will be not be seen by the other API
+(see http://pad.lv/948339 and http://pad.lv/948344 for details). Roughly,
+the old API always trigger an IO while the new one cache values to avoid
+them. This works fine as long as a given option is handled via a single API.
+
+Adding a new stack
+------------------
+
+Stacks capture the various places an option can be declared by the user with
+associated levels of generality and query them in the appropriate order
+returning the first definition found. For example, the
+``append_revisions_only`` option may be declared for all branches of a user
+in ``bazaar.conf``, or for a hierarchy of branches in ``locations.conf`` or
+in a single branch in ``branch.conf``.
+
+Defining a new stack means you need a new way to expose these levels to the
+user that is not covered by the existing stacks.
+
+This is achieved by declaring:
+
+* which stores can provide a value for the option,
+
+* which sections apply to the stack instance, some filtering for a given
+ context can be defined,
+
+* which (store, section) should receive the modifications.
+
+Mapping different sections to different stacks is a powerful way to organize
+the options and provide various levels of configuration to the user. This is
+achieved with ``Store`` and ``SectionMatcher`` objects.
+
+
+Adding a new store
+------------------
+
+The following stores are used by ``bzr`` in ways that illustrate various
+uses of sections.
+
+bazaar.conf
+===========
+
+``bzr`` itself defines two sections here:
+
+* ``DEFAULT`` where global options are defined,
+
+* ``ALIASES`` where command aliases are defined. This section is *not*
+ available via ``GlobalStack``, instead, the ``bzr alias`` command uses it
+ for its own purposes.
+
+Plugins can define either additional options in the ``DEFAULT`` section or
+new sections for their own needs (this is not especially encouraged
+though). The ``bzr-bookmarks`` plugin defines a ``BOOKMARKS`` section there
+for example.
+
+pkgimport.conf
+==============
+
+The Ubuntu package importer defines a store and two stacks involving
+``pkgimport.conf``. A no-name section contains the options common to all
+packages and sections named after their corresponding package can also be
+defined.
+
+The ``ImporterStack`` uses ``locations.conf`` and the no-name section in
+``pkgimport.conf`` for the importer options.
+
+The ``PackageStack`` uses only ``pkgimport.conf`` and uses the section name
+after the package followed by the no-name section.
+
+location.conf
+=============
+
+``bzr`` defines sections corresponding to URLs there and includes the
+relevant sections in ``LocationStack`` and ``BranchStack``. No no-name
+section is recognized in this file.
+
+branch.conf
+===========
+
+This file defines the option for a given branch and uses only the no-name
+section.
+
+Option
+------
+
+The Option object is used to define its properties:
+
+* name: a name: a valid python identifier (even if it's not used as an
+ identifier in python itself). This is also used to register the option.
+
+* from_unicode: a callable accepting a unicode string and returning a
+ suitable value for the option. If the string cannot be coerced it should
+ return None.
+
+* override_from_env: a list of environment variables. The first variable set
+ will be used as the option value overriding any other definition of the
+ option.
+
+* default: the default value that Stack.get() should return if no value can
+ be found for the option. This can also be a callable as long as it returns
+ a unicode string.
+
+* default_from_env: a list of environment variables. The first variable set
+ will provide a default value overriding 'default' which remains the
+ default value if *no* environment variable is set.
+
+* help: a doc string describing the option, the first line should be a
+ summary and can be followed by a blank line and a more detailed
+ explanation. This will be displayed to the user with::
+
+ bzr help <option name>
+
+* invalid: the action to be taken when an invalid value is encountered in a
+ store (during a Stack.get()).
+
+The value of an option is a unicode string or ``None`` if it's not
+defined. By using ``from_unicode`` you can turn this string into a more
+appropriate representation.
+
+If you need a list value, you should use ``ListOption`` instead.
+
+For options that take their values from a ``Registry`` object,
+``RegistryOption`` can be used. This will automatically take care of
+looking up the specified values in the dictionary and documenting the
+possible values in help.
+
+Sections
+--------
+
+Options are grouped into sections which share some properties with the well
+known dict objects:
+
+* the key is the name,
+* you can get, set and remove an option,
+* the value is a unicode string.
+
+MutableSection is needed to set or remove an option, ReadOnlySection should
+be used otherwise.
+
+
+Stores
+------
+
+Options can be persistent in which case they are saved into Stores.
+
+``config.Store`` defines the abstract interface that all stores should
+implement.
+
+This object doesn't provide direct access to the options, it only provides
+access to Sections. This is deliberate to ensure that sections can be
+properly shared by reusing the same underlying objects. Accessing options
+should be done via the ``Section`` objects.
+
+A ``Store`` can contain one or more sections, each section is uniquely
+identified by a unicode string.
+
+``config.IniFileStore`` is an implementation that use ``ConfigObj``.
+
+Depending on the object it is associated with (or not) a ``Store`` also needs
+to implement a locking mechanism. ``LockableIniFileStore`` implements such a
+mechanism for ``IniFileStore`` based stores.
+
+Classes are provided for the usual Bazaar configuration files and could be
+used as examples to define new ones if needed. The associated tests provides a
+basis for new classes which only need to register themselves in the right
+places to inherit from the existing basic tests and add their own specific
+ones.
+
+A ``Store`` defines how option values are stored, this includes:
+
+* defining the sections where the options are grouped,
+
+* defining how the values are quoted/unquoted for storage purposes. Stacks
+ use the unquoted values internally (default value handling and option
+ expansion are simpler this way) and ``bzr config`` quote them when they
+ need to be displayed.
+
+
+Filtering sections
+------------------
+
+For some contexts, only some sections from a given store will apply. The
+``SectionMatcher`` objects are used to define which sections in a store
+apply to a given context.
+
+The main constraint here is that a ``SectionMatcher`` should delay the loading
+of the associated store as long as possible. The constructor should collect
+all data needed for the selection and uses it while processing the sections in
+``get_sections``.
+
+Only ``ReadOnlySection`` objects are manipulated here but a
+``SectionMatcher`` can return dedicated ``Section`` objects to provide
+additional context (the ``LocationSection`` add an ``extra_path`` attribute
+to implement the section local options for example). If no sections match,
+an empty list is returned.
+
+Options local to a section can be defined for special purposes and be
+handled by ``Section.get()``. One such option is ``relpath`` which is
+defined in ``LocationSection`` as an alternative to the ``appendpath``
+policy.
+
+For ``appendpath``, the ``LocationSection`` will carry ``extra_path`` as the
+relative path between the section name and the location used. ``relpath``
+will be available as a ``Section`` local option with the same
+value. ``basename`` will carry the location base name and be available as a
+local option with the same name. Note that such options can only be expanded
+inside the section that defines them.
+
+Specific section matchers can be implemented by overriding ``get_sections``
+or just ``match``.
+
+``bzrlib`` provides:
+
+* ``NameMatcher(store, unique_id)``: To select a single section matching
+ ``unique_id``.
+
+* ``LocationMatcher(store, location)``: To select all sections that match
+ ``location`` sorted by decreasing number of path components.
+
+* ``StartingPathMatcher(store, location)``: To select all sections that
+ match ``location`` in the order they appear in the ``store``.
+
+Stacks
+------
+
+An option can take different values depending on the context it is
+used. This can involve configuration files, options from the command line,
+default values in bzrlib and then some.
+
+Such a context is implemented by creating a list of ``Section`` stacked upon
+each other. A ``Stack`` can then be asked for an option value and returns the
+first definition found.
+
+This provides a great flexibility to decide priorities between sections when
+the stack is defined without to worry about them in the code itself.
+
+A stack also defines a mutable section (which can be None) to handle
+modifications.
+
+Many sections (or even stores) are aimed at providing default values for an
+option but these sections shouldn't be modified lightly as modifying an option
+used for different contexts will indeed be seen by all these contexts.
+
+Default values in configuration files are defined by users. Developers
+shouldn't have to modify them, as such, no mechanism nor heuristics are used
+to find which section (or sections) should be modified.
+
+A ``Stack`` defines a mutable section when there is no ambiguity. If there
+is one, then the *user* should be able to decide and in this case a new
+``Stack`` can be created cheaply.
+
+Different stacks can be created for different purposes, the existing
+``GlobalStack``, ``LocationStack`` and ``BranchStack`` can be used as basis
+or examples. These classes are the only ones that should be used in code,
+``Stores`` can be used to build them but shouldn't be used otherwise, ditto
+for sections. Again, the associated tests could and should be used against the
+created stacks.
+
+Also note that ``MemoryStack`` can be used without any disk resources which
+allows for simpler and faster tests. A common pattern is to accept a
+``config`` parameter related to a given feature and test it with predefined
+configurations without involving the whole
+stack. ``bzrlib.tests.test_commit``, ``bzrlib.tests.test_gpg`` and
+``bzrlib.tests.test_smtp_connection`` are good examples.
+
diff --git a/doc/developers/container-format.txt b/doc/developers/container-format.txt
new file mode 100644
index 0000000..9e6d49b
--- /dev/null
+++ b/doc/developers/container-format.txt
@@ -0,0 +1,248 @@
+================
+Container format
+================
+
+Status
+======
+
+:Date: 2007-06-07
+
+This document describes the proposed container format for streaming and
+storing collections of data in Bazaar. Initially this will be used for
+streaming revision data for incremental push/pull in the smart server for
+0.18, but the intention is that this will be the basis for much more
+than just that use case.
+
+In particular, this document currently focuses almost exclusively on the
+streaming case, and not the on-disk storage case. It also does not
+discuss the APIs used to manipulate containers and their records.
+
+
+.. contents::
+
+
+Motivation
+==========
+
+To create a low-level file format which is suitable for solving the smart
+server latency problem and whose layout and requirements are extendable in
+future versions of Bazaar, and with no requirements that the smart server
+does not have today.
+
+
+Terminology
+===========
+
+A **container** is a streamable file that contains a series of
+**records**. Records may have **names**, and consist of bytes.
+
+
+Use Cases
+=========
+
+Here's a brief description of use cases this format is intended to
+support.
+
+Streaming data between a smart server and client
+------------------------------------------------
+
+It would be nice if we could combine multiple containers into a single
+stream by something no more expensive than concatenation (e.g. by omitting
+end/start marker pairs).
+
+This doesn't imply that such a combination necessarily produces a valid
+container (e.g. care must be taken to ensure that names are still unique
+in the combined container), or even a useful container. It is simply that
+the cost of assembling a new combined container is practically as cheap as
+simple concatenation.
+
+Incremental push or pull
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Consider the use case of incremental push/pull, which is currently (0.16)
+very slow on high-latency links due to the large number of round trips.
+What we'd like is something like the following.
+
+A client will make a request meaning "give me the knit contents for these
+revision IDs" (how the client determines which revision IDs it needs is
+unimportant here). In response, the server streams a single container of:
+
+ * one record per file-id:revision-id knit gzip contents and graph data,
+ * one record per inventory:revision-id knit gzip contents and graph
+ data,
+ * one record per revision knit gzip contents,
+ * one record per revision signature,
+ * end marker record.
+
+in that order.
+
+Persistent storage on disk
+--------------------------
+
+We want a storage format that allows lock-free writes, which suggests a
+format that uses *rename into place*, and *do not modify after writing*.
+
+Usable before deep model changes to Bazaar
+------------------------------------------
+
+We want a format we can use and refine sooner rather than later. So it
+should be usable before the anticipated model changes for Bazaar "1.0"
+land, while not conflicting with those changes either.
+
+Specifically, we'd like to have this format in Bazaar 0.18.
+
+Examples of possible record content
+-----------------------------------
+
+ * full texts of file versions
+ * deltas of full texts
+ * revisions
+ * inventories
+ * inventory as tree items e.g. the inventory data for 20 files
+ * revision signatures
+ * per-file graph data
+ * annotation cache
+
+
+Characteristics
+===============
+
+Some key aspects of the described format are discussed in this section.
+
+No length-prefixing of entire container
+---------------------------------------
+
+The overall container is not length-prefixed. Instead there is an end
+marker so that readers can determine when they have read the entire
+container. This also does not conflict with the goal of allowing
+single-pass writing.
+
+Structured as a self-contained series of records
+------------------------------------------------
+
+The container contains a series of *records*. Each record is
+self-delimiting. Record markers are lightweight. The overhead in terms
+of bytes and processing for records in this container vs. the raw contents
+of those records is minimal.
+
+Addressing records
+------------------
+
+There is a requirement that each object can be given an arbitrary name.
+Some version control systems address all content by the SHA-1 digest of
+that content, but this scheme is unsatisfactory for Bazaar's revision
+objects. We can still allow addressing by SHA-1 digest for those content
+types where it makes sense.
+
+Some proposed object names:
+
+ * to name a revision: "``revision:``\ *revision-id*". e.g.,
+ `revision:pqm@pqm.ubuntu.com-20070531210833-8ptk86ocu822hjd5`.
+ * to name an inventory delta: "``inventory.delta:``\ *revision-id*". e.g.,
+ `inventory.delta:pqm@pqm.ubuntu.com-20070531210833-8ptk86ocu822hjd5`.
+
+It seems likely that we may want to have multiple names for an object.
+This format allows that (by allowing multiple ``name`` headers in a Bytes
+record).
+
+Although records are in principle addressable by name, this specification
+alone doesn't provide for efficient access to a particular record given
+its name. It is intended that separate indexes will be maintained to
+provide this.
+
+It is acceptable to have records with no explicit name, if the expected
+use of them does not require them. For example:
+
+ * a record's content could be self-describing in the context of a
+ particular container, or
+ * a record could be accessed via an index based on SHA-1, or
+ * when streaming, the first record could be treated specially.
+
+Reasonably cheap for small records
+----------------------------------
+
+The overhead for storing fairly short records (tens of bytes, rather than
+thousands or millions) is minimal. The minimum overhead is 3 bytes plus
+the length of the decimal representation of the *length* value (for a
+record with no name).
+
+
+Specification
+=============
+
+This describes just a basic layer for storing a simple series of
+"records". This layer has no intrinsic understanding of the contents of
+those records.
+
+The format is:
+
+ * a **container lead-in**, "``Bazaar pack format 1 (introduced in 0.18)\n``",
+ * followed by one or more **records**.
+
+A record is:
+
+ * a 1 byte **kind marker**.
+ * 0 or more bytes of record content, depending on the record type.
+
+Record types
+------------
+
+End Marker
+~~~~~~~~~~
+
+An **End Marker** record:
+
+ * has a kind marker of "``E``",
+ * no content bytes.
+
+End Marker records signal the end of a container.
+
+Bytes
+~~~~~
+
+A **Bytes** record:
+
+ * has a kind marker of "``B``",
+ * followed by a mandatory **content length** [1]_:
+ "*number*\ ``\n``", where *number* is in decimal, e.g::
+
+ 1234
+
+ * followed by zero or more optional **names**:
+ "*name*\ ``\n``", e.g.::
+
+ revision:pqm@pqm.ubuntu.com-20070531210833-8ptk86ocu822hjd5
+
+ * followed by an **end of headers** byte: "``\n``",
+ * followed by some **bytes**, exactly as many as specified by the length
+ prefix header.
+
+So a Bytes record is a series of lines encoding the length and names (if
+any) followed by a body.
+
+For example, this is a possible Bytes record (including the kind marker)::
+
+ B26
+ example-name1
+ example-name2
+
+ abcdefghijklmnopqrstuvwxyz
+
+
+Names
+-----
+
+Names should be UTF-8 encoded strings, with no whitespace. Names should
+be unique within a single container, but no guarantee of uniqueness
+outside of the container is made by this layer. Names need to be at least
+one character long.
+
+
+.. [1] This requires that the writer of a record knows the full length of
+ the record up front, which typically means it will need to buffer an
+ entire record in memory. For the first version of this format this is
+ considered to be acceptable.
+
+..
+ vim: ft=rst tw=74 ai
+
diff --git a/doc/developers/content-filtering.txt b/doc/developers/content-filtering.txt
new file mode 100644
index 0000000..d3f5d89
--- /dev/null
+++ b/doc/developers/content-filtering.txt
@@ -0,0 +1,147 @@
+*****************
+Content Filtering
+*****************
+
+Content filtering is the feature by which Bazaar can do line-ending
+conversion or keyword expansion so that the files that appear in the
+working tree are not precisely the same as the files stored in the
+repository.
+
+This document describes the implementation; see the user guide for how to
+use it.
+
+
+We distinguish between the *canonical form* which is stored in the
+repository and the *convenient form* which is stored in the working tree.
+The convenient form will for example use OS-local newline conventions or
+have keywords expanded, and the canonical form will not. We use these
+names rather than eg "filtered" and "unfiltered" because filters are
+applied when both reading and writing so those names might cause
+confusion.
+
+Content filtering is only active on working trees that support it, which
+is format 2a and later.
+
+Content filtering is configured by rules that match file patterns.
+
+Filters
+*******
+
+Filters come in pairs: a read filter (reading convenient->canonical) and
+a write filter. There is no requirement that they be symmetric or that
+they be deterministic from the input, though in general both these
+properties will be true. Filters are allowed to change the size of the
+content, and things like line-ending conversion commonly will.
+
+Filters are fed a sequence of byte chunks (so that they don't have to
+hold the whole file in memory). There is no guarantee that the chunks
+will be aligned with line endings. Write filters are passed a context
+object through which they can obtain some information about eg which
+file they're working on. (See ``bzrlib.filters`` docstring.)
+
+These are at the moment strictly *content* filters: they can't make
+changes to the tree like changing the execute bit, file types, or
+adding/removing entries.
+
+Conventions
+***********
+
+bzrlib interfaces that aren't explicitly specified to deal with the
+convenient form should return the canonical form. Whenever we have the
+SHA1 hash of a file, it's the hash of the canonical form.
+
+
+Dirstate interactions
+*********************
+
+The dirstate file should store, in the column for the working copy, the cached
+hash and size of the canonical form, and the packed stat fingerprint for
+which that cache is valid. This implies that the stored size will
+in general be different to the size in the packed stat. (However, it
+may not always do this correctly - see
+<https://bugs.launchpad.net/bzr/+bug/418439>.)
+
+The dirstate is given a SHA1Provider instance by its tree. This class
+can calculate the (canonical) hash and size given a filename. This
+provides a hook by which the working tree can make sure that when the
+dirstate needs to get the hash of the file, it takes the filters into
+account.
+
+
+User interface
+**************
+
+Most commands that deal with the text of files present the
+canonical form. Some have options to choose.
+
+
+Performance considerations
+**************************
+
+Content filters can have serious performance implications. For example,
+getting the size of (the canonical form of) a file is easy and fast when
+there are no content filters: we simply stat it. However, when there
+are filters that might change the size of the file, determining the
+length of the canonical form requires reading in and filtering the whole
+file.
+
+Formats from 1.14 onwards support content filtering, so having fast
+paths for the case where content filtering is not possible is not
+generally worthwhile. In fact, they're probably harmful by causing
+extra edges in test coverage and performance.
+
+We need to have things be fast even when filters are in use and then
+possibly do a bit less work when there are no filters configured.
+
+
+Future ideas and open issues
+****************************
+
+* We might benefit from having filters declare some of their properties
+ statically, for example that they're deterministic or can round-trip
+ or won't change the length of the file. However, common cases like
+ crlf conversion are not guaranteed to round-trip and may change the
+ length, so perhaps adding separate cases will just complicate the code
+ and tests. So overall this does not seem worthwhile.
+
+* In a future workingtree format, it might be better not to separately
+ store the working-copy hash and size, but rather just a stat fingerprint
+ at which point it was known to have the same canonical form as the
+ basis tree.
+
+* It may be worthwhile to have a virtual Tree-like object that does
+ filtering, so there's a clean separation of filtering from the on-disk
+ state and the meaning of any object is clear. This would have some
+ risk of bugs where either code holds the wrong object, or their state
+ becomes inconsistent.
+
+ This would be useful in allowing you to get a filtered view of a
+ historical tree, eg to export it or diff it. At the moment export
+ needs to have its own code to do the filtering.
+
+ The convenient-form tree would talk to disk, and the convenient-form
+ tree would sit on top of that and be used by most other bzr code.
+
+ If we do this, we'd need to handle the fact that the on-disk tree,
+ which generally deals with all of the IO and generally works entirely
+ in convenient form, would also need to be told the canonical hash to
+ store in the dirstate. This can perhaps be handled by the
+ SHA1Provider or a similar hook.
+
+* Content filtering at the moment is a bit specific to on-disk trees:
+ for instance ``SHA1Provider`` goes directly to disk, but it seems like
+ this is not necessary.
+
+
+See also
+********
+
+* http://wiki.bazaar.canonical.com/LineEndings
+
+* http://wiki.bazaar.canonical.com/LineEndings/Roadmap
+
+* `Developer Documentation <index.html>`_
+
+* ``bzrlib.filters``
+
+.. vim: ft=rst tw=72
diff --git a/doc/developers/contribution-quickstart.txt b/doc/developers/contribution-quickstart.txt
new file mode 100644
index 0000000..6298935
--- /dev/null
+++ b/doc/developers/contribution-quickstart.txt
@@ -0,0 +1,134 @@
+Contributing to Bazaar
+======================
+
+Talk to us
+----------
+
+If you want to fix or improve something in Bazaar, we want to help you.
+You can ask at any time for help, on the list, on irc, or through a merge
+proposal on Launchpad.
+
+In particular, the rostered
+`Patch Pilot <http://wiki.bazaar.canonical.com/PatchPilot>`_
+is an experienced developer who will help you get your changes in, through
+code review, advice, debugging, writing tests, or whatever it takes.
+
+* `Bazaar mailing list <http://lists.ubuntu.com/mailman/listinfo/bazaar>`_
+
+* IRC in channel ``#bzr`` on ``irc.ubuntu.com``
+
+
+Starting
+--------
+
+Before starting on a change it's a good idea to either file a bug, find a
+relevant existing bug, or send a proposal to the list. If there is a bug
+you should set it to "In Progress" and if you wish assign it to yourself.
+
+You might like to start with a bug tagged `easy
+<https://bugs.launchpad.net/bzr/+bugs?field.tag=easy>`_.
+
+If you are wondering if your understanding of the bug is correct, or if the
+approach you have in mind is likely to work, feel to ask about it on the bug,
+in ``#bzr`` or on the mailing list.
+
+Making a branch
+---------------
+
+First, get a local copy of Bazaar::
+
+ $ cd $HOME
+ $ bzr init-repo bzr
+ $ cd bzr
+ $ bzr branch lp:bzr bzr.dev
+
+Now make your own branch; we recommend you include the bug number and also
+a brief description::
+
+ $ bzr branch bzr.dev 123456-status-speed
+
+and go ahead and commit in there. Normally you should fix only one bug or
+closely-related cluster of bugs per branch, to make reviews and merges
+flow more smoothly.
+
+For bugs that exist in older supported branches of bzr like 2.0 or 2.1,
+you might want to fix the bug there so it can go into a bugfix release,
+ie ::
+
+ $ bzr branch lp:bzr/2.1 bzr.2.1
+ $ bzr branch bzr.2.1 123458-2.1-status
+
+You probably want this configuration in ``~/.bazaar/locations.conf``::
+
+ [/home/USER/bzr]
+ push_location = lp:~LAUNCHPAD_USER/bzr/
+ push_location:policy = appendpath
+ public_branch = http://bazaar.launchpad.net/~LAUNCHPAD_USER/bzr/
+ public_branch:policy = appendpath
+
+with your local and Launchpad usernames inserted.
+
+
+
+Publishing your changes
+-----------------------
+
+After you've locally committed your changes, the configuration above
+should be enough that you can push them to Launchpad with a simple ::
+
+ $ bzr push
+
+
+Writing tests
+-------------
+
+We value test coverage and generally all changes should have or update a
+test. There is a powerful test framework but it can be hard to find the
+right place to put your test. Don't hesitate to ask, or to propose a
+merge that does not yet have tests.
+
+Normally for command-line code you should look in
+``bzrlib.tests.blackbox`` and for library code in ``bzrlib.tests``. For
+functions on an interface for which there are multiple implementations,
+like `Transport`, look in ``bzrlib.tests.per_transport``.
+
+It's a good idea to search the tests for something related to the thing
+you're changing and you may find a test you can modify or adapt.
+
+To run the tests::
+
+ $ ./bzr selftest
+
+Normally the tests will skip if some library dependencies are not present.
+On Ubuntu, you can install them with this command (you must have source
+repositories enabled in Software Sources)::
+
+ $ sudo apt-get build-dep bzr
+
+To build the binary extensions::
+
+ $ make
+
+For more information: `Testing Guide <testing.html>`_.
+
+
+Proposing a merge
+-----------------
+
+
+Then propose a merge into bzr; for bzr 2.2 and later you can use the ``bzr
+lp-propose-merge`` command. In the comment for your merge proposal please
+explain what you're trying to do and why. For `example
+<https://code.launchpad.net/~ian-clatworthy/bzr/whats-new-in-2.1/+merge/19677>`_:
+
+ As discussed on the mailing list, this patch adds a What's New document
+ summarising the changes since 2.0.
+
+If you make additional changes to your branch you don't need to resubmit;
+they'll automatically show up in the merge proposal.
+
+* `Launchpad Code Review Help <http://help.launchpad.net/Code/Review>`_.
+
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/cycle.txt b/doc/developers/cycle.txt
new file mode 100644
index 0000000..a1ad418
--- /dev/null
+++ b/doc/developers/cycle.txt
@@ -0,0 +1,427 @@
+*********************
+Bazaar Release Cycles
+*********************
+
+:status: Current policy, as of 2010-10.
+:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
+
+
+Our users want easy access to bug fixes without other changes to the
+core product. They also want a Just Works experience across the full
+Bazaar ecosystem. To deliver the first and enable the second, we're
+adopting some standard process patterns: a 6 monthly release cycle and a
+stable series. These changes will also have other benefits, including
+better availability of bug fixes in OS distributions, more freedom to
+remove old code, and less work for in packaging.
+
+See also:
+
+* `Bazaar Developer Document Catalog <index.html>`_
+
+* `Releasing Bazaar <releasing.html>`_ -- the process for actually making
+ a release or release candidate.
+
+
+The Process
+************
+
+Bazaar will make a major release every six months, which will be supported at
+least until the time of the next major release and generally 18 months after
+the first final release in a series. During this support period, we'll make
+incremental releases which fix bugs, but which do not change network or disk
+formats or command syntax, and which do not require updates to plugins.
+
+We will also run a development series, which will become the next major
+release. We'll make a beta release from this every four weeks. The
+beta releases will be as stable as our current monthly releases and
+completely suitable for everyday use by users who can tolerate changes
+from month to month.
+
+Having the stable series isn't a reason to cut back on QA or to make the
+trunk or development releases unstable, which would only make our job
+harder. We keep our trunk in an always-releasable state, and that should
+continue: any beta release could potentially be supported in the long
+term, but we identify particular releases that actually will be supported.
+
+The trunk will never be frozen: changes that pass review, other quality
+checks and that are agreed amongst the developers can always be landed
+into trunk. The only restrictions will be on branches specifically
+targeted at a release.
+
+
+Schedule
+--------
+
+::
+
+ 2.0.0 --- 2.0.1 -- 2.0.2 -- ...
+ \
+ +--2.1.0beta1 -- 2.1.0beta2 -- ... -- 2.1.0rc1 -- 2.1.0 -- 2.1.1 -- ...
+ \
+ \
+ +-- 3.0.0beta1 ...
+
+
+Starting from the date of a major release:
+
+At four-week intervals we make a new beta release. There will be no
+separate release candidate, but if a serious problem is discovered we may
+do the next beta ahead of schedule or make a point release. There will be
+about five or six releases in that series.
+
+In parallel with this, bugs targeted to the previous major release are
+merged into its branch. We will make bugfix releases from that branch as
+appropriate to the accumulation of changes, perhaps monthly, perhaps more
+often if there are serious bugs, perhaps much less often if no new changes
+have landed.
+
+We will synchronize our major releases with Ubuntu, so that they come out
+in sufficient time for some testing and margin of error before Ubuntu's
+upstream freeze.
+
+
+Regularity
+----------
+
+We value regular releases. We prefer to slip a feature or fix to
+a later release rather than to make a release late. We will normally only
+slip a release to fix a critical bug.
+
+
+Numbering
+---------
+
+The number for a six-month cycle is chosen at the start, with an increment
+to either the first field (3.0.0) or second field (3.1.0) depending on
+what we expect to be the user impact of the release. We expect releases
+that culminate in a new disk format or that require changes in how people
+use the tool will get a new major number. We can change (forward only) if
+it turns out that we land larger changes than were expected.
+
+We will always use the 3-digit form (major.minor.micro) even when
+referring to the initial major release. This should help clarify where a
+patch is intended to land. (eg, "I propose this for 2.0.0" is clear, while
+"I propose this for 2.0" could mean you want to make the 2.0.0 release, or
+that you just want to land on the 2.0.x stable release series.)
+
+
+Terminology
+-----------
+
+Major releases (2.0.0 or 2.1.0)
+
+ The big ones, every six months, intended to ship in distributions and
+ to be used by stability-oriented users.
+
+Release candidate (2.0.0rc1)
+
+ A preview of a major release, made one or a few weeks beforehand at the
+ time the release branch is created. There should be few if any changes
+ from the rc to the stable release. We should avoid the confusing phrasing
+ "release candidate 2.0.0rc1 is released"; instead use "available."
+ Starting with the 2.3 series we don't plan on making release candidates
+ anymore.
+
+Bugfix releases (2.0.1)
+
+ Based on the previous major release or bugfix; contains only bugfixes
+ and perhaps documentation or translation corrections.
+
+Stable series
+
+ A major release and its descendant bugfix releases.
+
+Stable release
+
+ Either a major release or a bugfix release.
+
+Beta release (3.0.0beta1)
+
+ Made from trunk every month, except for the month there's a major
+ release. Stable and suitable for users who want the latest code and
+ can live with some changes from month to month.
+
+Development series
+
+ The development releases leading up to a stable release.
+
+Bug Work
+--------
+
+Bug fixes should normally be done first against the stable branch,
+reviewed against that branch, and then merged forward to trunk.
+
+It may not always be easy to do this, if fixing the bug requires large
+changes or the affected code is different in the stable and development
+branches. If the tradeoff does not seem worthwhile the bug can be fixed
+only in the development branch, at least in the first instance. If users
+later want the fix backported we can discuss it.
+
+Developers can merge the release branch into trunk as often as they like,
+only asking for review if they're making nontrivial changes or feel review
+is needed.
+
+
+Feature and Performance Work
+----------------------------
+
+Features can be landed to the development branch at any time, and they'll
+be released for testing within a month.
+
+Performance bugs, although important, will generally not be landed in a
+stable series. Fixing performance bugs well often requires nontrivial
+code changes or new formats. These are not suitable for a stable series.
+
+Performance bugs that can be fixed with a small safe patch can be
+considered for the stable series.
+
+
+Plugins
+-------
+
+Plugins that want to cooperate with this should make a series and a branch
+that matches each bzr stable series, and follow similar rules in making
+releases from their stable branch. We'd expect that plugins will make a
+release between the first beta release of a series and the final major
+release.
+
+Within a stable series, anything that breaks any known plugin is
+considered an API break and will be avoided. Before
+making each bugfix release, we'll test that code against important
+plugins.
+
+Within a development series, the focus is on helping plugin authors keep
+up to date by giving clear error messages when an interface is removed.
+We will no longer focus on letting old plugin code work with new versions
+of bzrlib, which is an elusive target in Python.
+
+This may mean that in cases where today a plugin would keep running but
+give warnings, it will now fail altogether with an error.
+
+In return we expect more freedom to change and cleanup bzrlib code without
+needing to keep old code around, or write extra compatibility shims, or
+have review turnarounds related to compatibility. Some changes, such as
+removing module-global variables, that are hard to do now, will be
+possible to do safely.
+
+Discussion of plugins here includes programs that import and use bzrlib
+but that aren't technically plugins. The same approach, though the
+technical considerations are different, should apply to other extensions
+such as programs that use bzr through the shell interface.
+
+
+
+Data and Network Formats
+------------------------
+
+Any development release should be able to interoperate with the previous
+stable release, and any stable release should be able to interoperate with
+the previous stable release. This is a minimum and normally releases will be
+able to interoperate with all previous releases as at present.
+
+Each major release will have one recommended data format which will be the
+default. The name of the format will indicate which release series (not
+specific release) it comes from: '2a' is the first supported format for
+the 2.0.x series, '2b' the second, etc. We don't mention the particular
+release that introduced it so as to avoid problems predicting precisely
+when it will land.
+
+During a development series we may have a series of experimental formats.
+We will not leave people stranded if they test these formats, but we also
+won't guarantee to keep supporting them in a future release. If something
+inserted in one development release turns out to be bad it can just be
+removed in the next.
+
+
+Hosting Services
+-----------------
+
+The guarantees made above about format and network interoperation
+mean that hosting services such as Launchpad, Savannah, FedoraHosted,
+and Sourceforge could choose to run either the stable or beta versions.
+They might find it useful to run the beta version on their own beta
+server.
+
+
+Simultaneous Installation
+-------------------------
+
+Some people may want to simultaneously install and use both a stable
+release and development release.
+
+This can be handled in various ways either at the OS packaging or the
+Python level. We don't propose to directly address it in the upstream
+source. (For example, we will not change the bzrlib library name from one
+release to the next.)
+
+The issue already exists with people who may want to use for example the
+previous bzr release and the trunk. There is a related issue that plugins
+may be compatible with only some of the Bazaar versions people want to use
+at the same time, and again that is something that can be handled
+separately.
+
+
+OS Distributions
+----------------
+
+OS distributors will be recommended to ship the bzr stable release that
+fits their schedule, the betas leading up to that release during their own
+beta period, and the bugfix releases following on from it. They might
+also choose to offer the beta releases as an alternative package.
+
+
+Packaging
+---------
+
+At present we have three upstream-maintained PPAs containing Ubuntu packages
+of Bazaar: ``bzr/daily`` (snapshots), ``bzr-beta-ppa/ppa`` (beta releases) and
+``bzr/ppa`` (ie stable). Beta contains the monthly beta releases, and the
+stable PPA contains stable releases and bugfixes to those releases.
+
+Some platforms with relatively less active packagers may choose to ship
+only the stable releases. This is probably better than having them only
+intermittently or slowly ship the monthly releases.
+
+Binary installers should use a version number like '2.0.0-1' or
+'2.0.0beta1-1' so that the last component just reflects the packaging
+version, and can be incremented if a new installer is made with no
+upstream source changes.
+
+
+Code Freeze vs Announcement
+---------------------------
+
+We will separate the code freeze for a particular release from its actual
+announcement, allowing a window of approximately one week for plugins to
+be released and binary installers to be built. On the date the
+announcement is published, people will be able to easily install it.
+
+
+Weekly Metronome Mail
+---------------------
+
+Every week the release manager should send a mail to the Bazaar list
+covering these points (as appropriate):
+
+* Early communication about changing dependencies or defaults
+
+* Reminder re lifecycle and where we're up to right now, in particular the
+ dates for the next release and/or candidate.
+
+* Summary of recent successes and pending work.
+
+* Reminder re release objectives
+
+* Reminder re things needing attention, e.g. bug triage, reviews, testing
+ of certain things, etc.
+
+
+Questions
+*********
+
+Do users actually want this?
+ Apparently yes, because it's often requested and often raised as a
+ problem.
+
+Would this confuse users?
+ It shouldn't, because it's a fairly standard scheme.
+
+Won't it take more time to fix bugs in multiple places?
+ It shouldn't, because we'll only do this when the stable bugfix seems
+ economical. When we fix bugs today in both trunk and release branches
+ it normally does not take much more time.
+
+What about bzr in Ubuntu LTS, with a five-year support life?
+ Most bugs are either fixed within six months, or not fixed at all, or
+ not very important, or fixed as part of a large rework of the code
+ that would be too large to backport. However, if there are fixes that
+ are especially desired in an old release and feasible to do, we can do
+ them without making a general commitment.
+
+Will anyone test the beta releases?
+ Probably yes, our most active users will run them, but if people would
+ really rather not test them, forcing them is not helpful.
+
+Isn't this a step backwards to a slower, less-agile process?
+ No, our trunk stays releasable, and we ship every month. We're just
+ cutting out things that hold us back (continuous rather than episodic
+ API stability; RCs every month) and giving users what they demand.
+
+How about calling the monthly releases "milestone" or "next" not "beta"?
+ Those words are less scary but they also have less clear meanings.
+
+
+Expected Benefits
+*****************
+
+If this plan works, we'll expect to see the following changes. If they
+don't occur, we'll think again:
+
+* We see a distribution curve of users and bug reports across nightly, monthly
+ and stable releases, indicating that each has value.
+
+* API changes are easier or safer to make during beta periods, without
+ being held back by fears of compatibility or
+
+* The stable releases are actually stable and don't introduce regressions
+ or break plugins.
+
+* Many bugs are fixed in stable branches, without developers feeling this
+ is a waste of time.
+
+* Distributions ship the stable releases in their stable releases and the
+ bugfix releases in their bugfix releases.
+
+* Plugin authors follow this policy, making their own bugfix releases.
+
+* Users like it.
+
+After doing this for the 2.0 cycle (September 2009 through to early
+2010), it seems to be going well.
+
+
+Reviewing for the Stable Branch
+*******************************
+
+These are guidelines and can be interpreted case-by-case.
+
+* All changes to the stable branch should fix a bug, even if you would not
+ normally file a bug for the change. The bug description should if at
+ all possible explain how to manually verify the bug in a way that will
+ fail before and pass after the change. (These are requirements for the
+ SRU process.)
+
+* The change should be reasonably small and conservative.
+
+* Remember that the patch will be read during the SRU
+ process and so keeping the patch small is useful even beyond keeping the
+ logical changes small. Avoid doing mechanical bulk changes on the
+ stable branch.
+
+* Use particular care for things that may behave differently across
+ platforms, encodings or locales. It's harder to thoroughly test these
+ things before a release.
+
+* Generally speaking, just cleaning things up is not a sufficient reason
+ to make changes to the stable branch. It has to actually fix a bug.
+
+* Changes to the stable branch should include tests as usual.
+
+* Don't change or remove existing APIs that might be used by plugins, even
+ if they are underscore-prefixed. Adding APIs that are also being added
+ to the trunk branch may make sense.
+
+* Keeping consistency with trunk is useful, but less important than
+ keeping the stable branch stable.
+
+* (more items welcome)
+
+References
+**********
+
+#. List thread "`[rfc] six-month stable release cycles`__", July 2009.
+
+.. __: https://lists.ubuntu.com/archives/bazaar/2009q3/060882.html
+
+..
+ vim: filetype=rst textwidth=74 ai shiftwidth=4
diff --git a/doc/developers/development-repo.txt b/doc/developers/development-repo.txt
new file mode 100644
index 0000000..761fad5
--- /dev/null
+++ b/doc/developers/development-repo.txt
@@ -0,0 +1,277 @@
+==============================
+Development repository formats
+==============================
+
+.. contents::
+
+Using development repository formats
+====================================
+
+Motivation
+----------
+
+We believe that we can continue to gain substantial performance benefits
+by altering the repository storage in bzr. The more feedback we can get
+on the changes during the development process the better.
+
+To make it possible to get more feedback we are going to expose the
+current development formats to the users of our development trunk
+'bzr.dev'. The technical details of the individual formats are at the
+end of this document.
+
+Format names
+------------
+
+The current development format will be called 'development'. Each time
+the development format changes, the prior development format will be
+renamed to e.g. 'development0', 'development1' etc.
+
+When a release of bzr is done, all the older numbered development
+formats will be removed from 'bzr.dev', so we will not be carrying the
+code for them around indefinately.
+
+Support for upgrade and migration
+---------------------------------
+
+The preservation and renaming policy makes it quite safe for users to
+test out development formats (though we cannot guarantee bugs of course
+- it is development code):
+
+ - users of a given development format can always get back onto regular
+ formats by switching to the next bzr released version which is
+ guaranteed to be able to upgrade from that development format.
+ - users that routinely use bzr.dev should upgrade to the most recent
+ development version available before pulling in bzr.dev changes
+ around release time, as that is when old format cleanups will occur.
+
+We cannot guarantee backwards compatability though, because some of the
+planned work may be 'upgrade only'. Please see ``bzr help formats`` for
+the text of the 'development' format which will indicate its
+compatability with other formats if you need to interoperate with
+users or services that do not have bzr.dev.
+
+Before converting to a development format
+-----------------------------------------
+
+Run a ``bzr check`` with the version of bzr that you will be using.
+``bzr check`` gets updated as we find new things that are inconsistent
+with existing repositories. While only a small number of repositories
+are likely to have any given error, it is best to check just in case.
+
+If ``bzr check`` reports a problem, run this command::
+
+ bzr reconcile
+
+Note that reconcile can take many hours, particularly if you are
+reconciling one of the 'knit' or 'dirstate' format repositories. If you
+have such a repository, consider upgrading it to 'pack-0.92' first,
+which will perform reconcile significantly faster.
+
+Creating a new development format branch
+----------------------------------------
+
+If you're starting a project from scratch, it's easy to make it a
+``development`` one. Here's how::
+
+ cd my-stuff
+ bzr init --development
+ bzr add
+ bzr commit -m "initial import"
+
+In other words, use the normal sequence of commands but add the
+``--development`` option to the ``init`` command.
+
+
+Creating a new development format repository
+--------------------------------------------
+
+If you're starting a project from scratch and wish to use a shared repository
+for branches, you can make it a ``development`` repository like this::
+
+ cd my-repo
+ bzr init-repo --development .
+ cd my-stuff
+ bzr init
+ bzr add
+ bzr commit -m "initial import"
+
+In other words, use the normal sequence of commands but add the
+``--development`` option to the ``init-repo`` command.
+
+Upgrading an existing branch or repository to development
+---------------------------------------------------------
+
+If you have an existing branch and wish to migrate it to
+a ``development`` format, use the ``upgrade`` command like this::
+
+ bzr upgrade --development path-to-my-branch
+
+If you are using a shared repository, run::
+
+ bzr upgrade --development ROOT_OF_REPOSITORY
+
+to upgrade the history database. Note that this will not
+alter the branch format of each branch, so
+you will need to also upgrade each branch individually
+if you are upgrading from an old (e.g. < 0.17) bzr.
+More modern bzr's will already have the branch format at
+our latest branch format which adds support for tags.
+
+Starting a new development format branch from one in an older format
+--------------------------------------------------------------------
+
+This can be done in one of several ways:
+
+1. Create a new branch and pull into it
+2. Create a standalone branch and upgrade its format
+3. Create a knitpack shared repository and branch into it
+
+Here are the commands for using the ``pull`` approach::
+
+ bzr init --development my-new-branch
+ cd my-new-branch
+ bzr pull my-source-branch
+
+Here are the commands for using the ``upgrade`` approach::
+
+ bzr branch my-source-branch my-new-branch
+ cd my-new-branch
+ bzr upgrade --development .
+
+Here are the commands for the shared repository approach::
+
+ cd my-repo
+ bzr init-repo --development .
+ bzr branch my-source-branch my-new-branch
+ cd my-new-branch
+
+As a reminder, any of the above approaches can fail if the source branch
+has inconsistent data within it and hasn't been reconciled yet. Please
+be sure to check that before reporting problems.
+
+Develoment formats for bzr-svn users
+------------------------------------
+
+If you are using ``bzr-svn`` or are testing the prototype subtree support,
+you can still use and assist in testing the development formats. The
+commands to use are identical to the ones given above except that the
+name of the format to use is ``development-subtree``.
+
+**WARNING**: Note that bzr only supports one-way conversion **to** the
+subtree format ``development-subtree``. Once you are using
+``development-subtree`` you cannot pull or merge back into a regular
+format such as ``pack-0.92``, ``development`` etc.
+
+The ``development-subtree`` format is required for the bzr-svn
+plug-in but should otherwise not be used until the subtree feature is
+complete within bzr.
+
+Reporting problems
+------------------
+
+If you need any help or encounter any problems, please contact the developers
+via the usual ways, i.e. chat to us on IRC or send a message to our mailing
+list. See http://wiki.bazaar.canonical.com/BzrSupport for contact details.
+
+
+Technical notes
+===============
+
+When to create a new development format
+---------------------------------------
+
+Whenever a code change will result in incorrect behaviour with existing
+``development`` repositories. Changes in push/pull/init/commit/merge
+have all been known to do this in the past.
+
+How to create a new development format
+--------------------------------------
+
+1. Register two new formats with the next available sequence number.
+ e.g. ``development1`` and ``development1-subtree``. (You can see the
+ current development format for an example.
+ These should:
+
+ * Use your new development repository/branch/tree classes
+ * Have really bare bones help - something like 'changes X to be Y
+ see ...developers/development-repo.html'
+ * Be hidden and experimental.
+2. Change the repository class (or branch or tree) in the
+ ``development`` and ``development-subtree`` formats to point to the
+ new class you are creating.
+3. Add a new development format (and tests!). Repository formats are in
+ ``bzrlib.repofmt``. You probably want to reproduce the current
+ development format from ``bzrlib.repofmt.pack_repo`` with just new
+ disk format strings, ``_get_matching_bzrdir`` and help.
+4. Register your development format with the various registries. At the
+ moment you need to update:
+
+ 1. ``bzrlib/bzrdir.py`` to register the WT/Branch/Repository
+ collection.
+
+ 2. ``bzrlib/workingtree.py``, ``bzrlib/branch.py``,
+ ``bzrlib/repository.py``, each one maintains a direct list of
+ their respective formats.
+
+ 3. For repositories, you also need to update the InterKnit1and2
+ class. This is responsible for converting between rich-root and
+ non-rich-root repositories.
+
+ 4. For repositories based on KnitPackRepository, you need to update
+ ``bzrlib/tests/test_pack_repository.py`` to add the class to the
+ tested permutations.
+
+5. Alter any other things that do class based tests. The easiest way
+ to find these is a grep for Development in bzrlib - and please
+ refactor as you find these to reduce the relevance this step has,
+ as it should not need to exist.
+6. Now subclass/create from scratch/whatever the live object code you
+ need to change to introduce your new format. Keep in mind that
+ eventually it will become the default format, so please don't keep
+ subclassing the last releases code, rather consider making the last
+ releases code a subclass of your new code (if there is a lot in
+ common) so that we can eventually remove that format once it becomes
+ ancient (or relegate it to a plugin).
+7. Once you have made the changes that required a new disk format, you
+ should submit the resulting branch to be merged. Other changes - to
+ take advantage of whatever new feature you have added - should be
+ sent in separately, because the disk level changes are a contention
+ point between multiple developers.
+
+Format Details
+==============
+
+development
+-----------
+
+Not currently available, as our development formats are all rich root or
+subtrees now.
+
+development-rich-root
+---------------------
+
+Currently an alias for Development6Subtree
+
+development-subtree
+-------------------
+
+Currently an alias for Development6Subtree
+
+Development6RichRoot[Subtree]
+-----------------------------
+
+These formats use the new groupcompress delta compress and a CHK(Content
+Hash Key) based inventory store which is much faster at incremental
+operations than the prior XML based store.
+*Note* Converting from a non-rich-root to a rich-root format is a
+one-way upgrade, and you cannot merge back afterwards: using this format
+for everyday use is likely to cause all developers of a project to
+upgrade to a rich-root format themselves. This is fine, as bzr is moving
+to make rich-root formats the default and to get all users to upgrade,
+but we have not finalised the migration process, and until we do do not
+recomment that casual users upgrade. Users of bzr-svn are already using
+rich-root formats and can test with this with impunity.
+
+
+..
+ vim: tw=72 ft=rst expandtab
diff --git a/doc/developers/diff.txt b/doc/developers/diff.txt
new file mode 100644
index 0000000..8ea482e
--- /dev/null
+++ b/doc/developers/diff.txt
@@ -0,0 +1,110 @@
+diff Performance Analysis
+=========================
+
+.. contents:: :local:
+
+Minimal Work
+------------
+
+Reuse of historical comparisons
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+A significant part of the work done by diff is sequence matching. This
+scales O(n^2) with the number of lines in the file. Therefore, it
+is worthwile to avoid content comparisons as much as possible.
+
+Our current knit format contains content comparisons, and this data can
+be converted into lists of matching blocks. Other future formats such as
+mpdiff may also support such conversion. So it is possible to reuse past
+comparisons.
+
+It is also possible to combine sequential comparisons. So given a comparison
+of "foo" to "bar", and "bar" to "baz", it is possible to derive a comparison of
+"foo" to "baz".
+
+Reuse of historical comparisons will scale with the number of uncommon
+build-parents between the two historical revisions. This will typically be
+proportional to the amount of change that the file has undergone. Therefore,
+in the common case, reuse of historical comparisons will scale with the
+amount of change.
+
+The downside of such reuse is that it ties the comparison to the historical
+data. But given the performance improvement, it seems to be worth
+consideration. Fresh comparisons can be performed if the user requests them.
+
+It may also be possible to accelerate comparisons by including annotation data,
+thus increasing the number of unique lines.
+
+Historical Tree Against Historical Tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This operation should be strictly proportional to the amount of change, because
+a comparison has already been done at commit time. Achieving that performance
+requires the committed data to be properly structured, so that the comparison
+can be extracted and combined with other comparisons. This comparision
+extraction should be possible at the inventory and file-content levels.
+
+Minimum work:
+
+1. Extract and combine inventory comparisons
+2. Extract and combine text comparisions for modified texts
+
+Basis Against Historical Tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This is another case of Historical Tree Against Historical Tree.
+
+Basis Against Basis
+~~~~~~~~~~~~~~~~~~~
+This is another case of Historical Tree Against Historical Tree.
+
+Working Tree Against Basis
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+This must scale with the number of versioned files, unless the user indicates
+that only certain files should be compared.
+
+Performance can be further improved by caching comparisons to avoid repeating
+them. Caching could potentially be performed by ``diff`` and perhaps by
+``merge``. Merge is aware of the relationship of a text merge's result to
+the THIS value, and the THIS value is generally the basis value. So the
+comparison is latent, but present. The only issue is extracting it.
+
+The cache could be indexed by sha1sum pairs. It could also be indexed by
+file-id, to facilitate removal of stale data.
+
+Minimum work:
+
+1. Scan working tree for modified files
+2. Retrieve cached comparisons
+3. Perform comparisons on files with no cached comparisons
+4. Cache comparisons for files with no cached comparisons
+
+Working Tree Against Historical Tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This can be structured as a comparison of working tree against basis tree,
+followed by basis tree against historical tree. Therefore, it combines the
+performance characteristics of "Working Tree Against Basis" with "Basis Against
+Historical Tree".
+
+Working Tree Against Working Tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This can be structured as two comparisons against basis, and one comparison
+of basis against basis. Its performance is therefore similar to Working Tree
+Against Historical Tree.
+
+API Changes
+-----------
+
+Desired API:
+
+ - Tree.get_comparision(file_id, tree)
+
+This probably entails:
+
+ - WorkingTree.store_comparison(file_id, revision_id, sha1, comparison)
+ - WorkingTree.get_comparison(file_id, revision_id, sha1)
+ - Repository.get_comparision(file_id, revision_id, revision_id)
+ - merge_comparisions(comparison, comparision)
+
+Storage considerations
+----------------------
+It must be cheap (e.g. scale with number of intermediate revisions) to perform
+comparison of two historical texts. It must be cheap to perform comparison of
+the inventories of two historical trees.
diff --git a/doc/developers/directory-fingerprints.txt b/doc/developers/directory-fingerprints.txt
new file mode 100644
index 0000000..a3e042e
--- /dev/null
+++ b/doc/developers/directory-fingerprints.txt
@@ -0,0 +1,359 @@
+Directory fingerprints
+======================
+
+.. contents:: :local:
+
+Introduction
+------------
+
+The basic idea is that for a directory in a tree (committed or otherwise), we
+will have a single scalar value. If these values are the same, the contents of
+the subtree under that directory are necessarily the same.
+
+This is intended to help with these use cases, by allowing them to quickly skip
+over directories with no relevant changes, and to detect when a directory has
+changed:
+
+* diff/status (both local trees and historical trees)
+* merge
+* log -v
+* log on a directory
+* commit
+
+
+Use-case oriented APIs
+----------------------
+
+Most of this will be hidden behind the Tree interface. This should cover
+``log -v``, ``diff``, ``status``, ``merge`` (and implicit merge during
+push, pull, update)::
+
+ tree.iter_changes(other_tree)
+ tree.get_file_lines(file_id) # and get_file, get_file_text
+
+``commit``
+~~~~~~~~~~
+
+Commit is similar to ``iter_changes``, but different because it needs to
+compare to all the trees. Commit currently needs to compare the working
+tree to all the parent trees, which is needed to update the last_modified
+field and would be unnecessary if we removed that field (for both files
+and directories) and did not store per-file graphs.
+This would potentially speed up commit after merge.
+
+Verbose commit also displays the merged files, which does
+require looking at all parents of files that aren't identical
+to the left-hand parent.
+
+``log``
+~~~~~~~
+
+Log is interested in two operations: finding the revisions that touched
+anything inside a directory, and getting the differences between
+consecutive revisions (possibly filtered to a directory)::
+
+ find_touching_revisions(branch, file_id) # should be on Branch?
+
+Log shows the revisions that merged a change. At the moment that is not
+included in the per-file graph, and it would also not be visible if the
+directories were hashed.
+
+
+
+
+Open questions
+--------------
+
+* Is this a good idea at all?
+
+ If changing a file changes all its parent directories up to the root it
+ will cause more churn on commit. (We currently update the all-in-one
+ inventory, but only have to update one line of it.)
+
+ Every time a child changes, we'll get a new node in the per-directory
+ graph. This is generally useful: it allows bzr log to do the default
+ mode easily, which is to show all changes under that directory. The
+ less common operation, ``log --no-recursive`` is still possible by
+ looking only at when the directory itself was renamed, added or removed.
+ (That is what the directory graph describes in bzr 0.18 and it is rarely
+ useful.)
+
+
+* Should these be hashes or revision ids or something else?
+
+ Pros of using hashes: hashes are easy to generate by a foreign branch
+ plugin (e.g. bzr-svn). They don't need to get recursive last-changed
+ from the foreign branch, or to walk back through history. They just
+ need the relevant directory state, which any system we support can
+ answer.
+
+ Hashes converge: if you modify and then modify back, you get the same
+ hash. This is a pro because you can detect that there were ultimately
+ no significant changes. And also a con: you cannot use these hashes to form a graph
+ because they get cycles.
+
+
+* Are the values unique across the whole tree, or only when comparing
+ different versions of the same object?
+
+ If we use last-changed revisions, then they will be very not unique
+ across the whole tree. To look up the contents, you must pass a
+ composite key like ``(file_id, last_changed)``.
+
+ If we use hashes they will be same only when the two contain the same
+ contents. Since we say that file ids must be unique, this
+ means they will match if and only if they are empty. We might relax
+ that in future when we introduce path tokens.
+
+
+* Is it reasonable to assume hashes won't collide?
+
+ The odds of SHA-1 hashes colliding "accidentally" are vanishingly small.
+
+ It is possible that a `preimage attack`_ against SHA-1 may be discovered
+ in the future. Since we're not proposing in this document to make
+ revision-ids be SHA-1, if SHA-1 was obsoleted then we could rewrite the
+ contents of revisions but would not need to rename revisions. So the
+ impact of such a migration should just be a format upgrade, and a
+ recommendation (but not requirement) to re-sign revisions.
+
+.. _`preimage attack`: http://tools.ietf.org/html/rfc4270
+
+
+* If we use hashes, should it be the hash of the
+ representation stored for a directory?
+
+ In other words, should we pun the representation of the directory with
+ the form used for validation.
+
+ If there's some data stored that's not in the hash it's problematic.
+ The hash in no longer (effectively) uniquely identifies the
+ representation.
+
+ It is desirable that we have a hash that covers all data, to guard
+ against bugs, transmission errors, or users trying to hand-hack files.
+ Since we need one hash of everything in the tree, perhaps we should also
+ use it for the fingerprint.
+
+ Testaments explicitly separate the form used for hashing/signing from
+ the form used for storage. This allows us to change the storage form
+ without breaking existing GPG signatures. The downside is that we need
+ to do work O(tree) to make a testament, and this slows down signing,
+ verifying and generating bundles. It also means that there is some
+ stored data which is not protected by the signature: this data is less
+ important, but corruption of it would still cause problems.
+ We have encountered some specific problems with disagreement between
+ inventories as to the last-change of files, which is currently unsigned.
+ These problems can be introduced by ghosts.
+
+ If we hash the representation, there is still a way to support old
+ signatures, assuming that we never discard irreplaceable information.
+ The signature should say what format it applies to (similar to
+ testaments), and we could transform in memory the tree back to that
+ format.
+
+
+* Is hashing substantially slower than other possible approaches?
+
+ We already hash all the plain files. Except in unusual cases, the
+ directory metadata will be substantially smaller: perhaps 200:1 as a
+ rule of thumb.
+
+ When building a bzr tree, we spend on the order of 100ms hashing all the
+ source lines to validate them (about 13MB of source).
+
+
+* Can you calculate one from a directory in the working tree? Without a basis?
+
+ This seems possible with either hashes or revision ids.
+
+ Using last_changed means that calculating the fingerprint from a working
+ tree necessarily requires reading the inventory for the basis
+ revision, so that we know when unchanged files were last changed. With
+ hashes we could calculate them using the working tree information alone.
+ It's true that we will often then compare that information to the basis
+ tree (e.g. for simple ``bzr diff``), but we may only have to compare at
+ the top level, and sometimes we're comparing to a
+ different tree. This also touches on whether we should store
+ ``last_modified`` for files, rather than directories.
+
+ For revision ids we need to assign a value to use for uncommitted
+ changes, but see below about the problems of this.
+
+ In some ways it would be elegant to say (hypothetical)::
+
+ wt.get_root().get_last_modified() == branch.get_last_revision()
+
+ to know that nothing was changed; but this may not be much better than
+ ::
+
+ wt.get_root().get_hash() ==
+ branch.get_basis().get_root().get_hash()
+
+
+* Can you use this to compare (directories from) two working trees?
+
+ If you can generate it from a working tree, you should be able to use it
+ to compare them.
+
+ This does rule out for example using ``last_modified=None`` or
+ ``='current:'`` to mean "changed in the working tree." Even if this is
+ not supported there seems some risk that we would get the same
+ fingerprint for trees that are actually different.
+
+ We could assign a
+ hypothetical revision id to the tree for uncommitted files. In that
+ case there is some risk that the not-yet-committed id would become
+ visible or committed.
+
+
+* Can we use an "approximate basis"?
+
+ When using radix trees, you may need context beyond the specific
+ directory being compared.
+
+
+* Can you get the fingerprint of parents directories with only selected file ids
+ taken from the working tree?
+
+ With hashes, we'd want to carry through the unselected files and
+ directories from the values they had in the parent revision.
+
+
+* Are unbalanced trees a significant problem? Trees can be unbalanced by having
+ many directories (deep or wide), or many files per directory.
+
+ For small trees like bzr, 744 of 874 are in the bzrlib subtree. In
+ general, larger trees are more balanced, because humans, editors and
+ other tools have trouble managing very unbalanced trees. But there are
+ exceptions: Aaron has one tree with 20,000 generated but versioned
+ entries in one directory.
+
+
+* Should we use a radix tree approach where fingerprints are calculated on a synthetic
+ tree that is by definition balanced, even when the actual tree is unbalanced?
+
+
+* What are the specific advantages of using recursive-last-modified rather than
+ hashes?
+
+ It may be a smaller step change.
+
+ It's a bidirectional link: given a directory text identifier ``(file_id,
+ last_changed)`` you can look up the revision that last changed it.
+
+ From the preceding, even without the per-file graph you can skip through
+ the history of this file: go to the last-changed revision, look at all
+ its parents and repeat.
+
+
+* Is it a smaller change to use recursive-last-modified on directories?
+
+ Probably yes:
+
+ 1. We can just put it into the current inventory format without changing
+ anything else.
+
+ By contrast to use a hash we'd have to either split up the inventory
+ as stored, or change the sort order for the inventory, or synthesize
+ per-directory inventories in memory for hashing.
+
+ However, XML is somewhat redundant and slow to parse/generate; and
+ reading the whole thing before comparing some sections is only a
+ partial win. It may be a smaller change but we'd be preserving
+ things we want to change.
+
+ 1. At present we rarely hash storage representations, only file texts.
+ This is not a large technical change, but it is a conceptual change.
+ This has some consequences for how we can upgrade it in future: all
+ the changed directories need to be rewritten up to the revision level.
+
+ 1. If we address directories by hash we need hash-addressed
+ storage.
+
+ 1. If we address directories by hash then for consistency we'd probably
+ (not necessarily) want to address file texts by hash.
+
+ 1. The per-file graph can't be indexed by hash because they can converge, so we
+ need to either rework or dispose of the per-file graph.
+
+
+* Any possibilities for avoiding hashes recurring?
+
+ 1. Hash along with an identification of the parents (as in hg). Then you
+ can't convert a tree without all its basis trees, and there is still
+ convergence when the same merge is done by two people, and you can't
+ create it directly from the working tree.
+
+ 1. Include last-modified revision id in the hash.
+
+ 1. Index by ``(revision, hash)`` or vice versa.
+
+ 1. Store a per-file graph and allow it to have repeated keys. The graph
+ would tell you about all the parent texts ever seen; you would need
+ to use revision graph information to resolve ambiguities.
+
+
+* What are the specific disadvantages of using recursive-last-modified rather than
+ hashes?
+
+ To calculate the last-changed revision, given the last-changed
+ information of the contained files, you need to look at the revision
+ graph. They're not enough because you need to know the relations
+ between the mentioned revisions. In a merge it's possible the correct
+ directory last-modified will not be the same as that of any of the files
+ within it. This can also happen when a file is removed (deleted or
+ renamed) from a directory.
+
+
+* Should we split up storage of the inventories?
+
+ This is not quite the same but connected.
+
+
+* How does this relate to per-file/per-directory hashes?
+
+ If the version of a file or directory is identified by a hash, we can't
+ use that to point into a per-file graph. We can have a graph indexed by
+ ``(file_id, hash, revision_id)``. The last-modified could be stored as
+ part of this graph.
+
+ The graph would no longer be core data; it could be always present but
+ might be rebuilt. Treating it as non-core data may make some changes
+ like shallow branches easier?
+
+
+* How do you ask a tree for a given text?
+
+ Right now we say ::
+
+ revision_tree.get_file_lines(file_id)
+
+ so the choice of storage is hidden behind the revision tree: it could be
+ accessed by ``(file_id, last_changed)`` or by hash or otherwise.
+
+ At the moment the Repository exports a friend api to RevisionTree,
+ currently usually talking in VersionedFiles.
+
+ We probably wouldn't want Repository to expose a ``get_text_for_sha1()``
+ interface because that would be very difficult to support on old
+ repositories or on foreign branches.
+
+
+Conclusions
+-----------
+
+
+Design changes
+--------------
+
+
+
+
+API changes
+-----------
+
+
+..
+ vim: filetype=rst textwidth=78 expandtab spelllang=en spell
+
diff --git a/doc/developers/dirstate.txt b/doc/developers/dirstate.txt
new file mode 100644
index 0000000..c1a7b5a
--- /dev/null
+++ b/doc/developers/dirstate.txt
@@ -0,0 +1,60 @@
+Dirstate
+========
+
+Don't really need the hashes of the current versions - just knowing
+whether they've changed or not will generally be enough - and just the
+mtime and ctime of a point in time may be enough?
+
+
+``_dirblock_state``
+-------------------
+
+There are currently 4 levels that state can have.
+
+ 1. NOT_IN_MEMORY
+ The actual content blocks have not been read at all.
+ 2. IN_MEMORY_UNMODIFIED
+ The content blocks have been read and are available for use. They have
+ not been changed at all versus what was written on disk when we read
+ them.
+ 3. IN_MEMORY_HASH_MODIFIED
+ We have updated the in-memory state, but only to record the
+ sha1/symlink target value and the stat value that means this
+ information is 'fresh'.
+ 4. IN_MEMORY_MODIFIED
+ We have updated an actual record. (Parent lists, added a new file,
+ deleted something, etc.) In this state, we must always write out the
+ dirstate, or some user action will be lost.
+
+
+IN_MEMORY_HASH_MODIFIED
+~~~~~~~~~~~~~~~~~~~~~~~
+
+This state is a bit special, so deserves its own topic. If we are
+IN_MEMORY_HASH_MODIFIED, we only write out the dirstate if enough records
+have been updated. The idea is that if we would save future I/O by writing
+an updated dirstate, then we should do so. The threshold for this is set
+by "worth_saving_limit". The default is that at least 10 entries must be
+updated in order to consider the dirstate file worth updating.
+
+Going one step further, newly added files, symlinks, and directory entries
+updates are treated specially. We know that we will always stat all
+entries in the tree so that we can observe *if* they have changed. In the
+case of directories, all the information we know about them is just from
+that stat value. There is no extra content to read. So an update directory
+entry doesn't cause us to update to IN_MEMORY_HASH_MODIFIED. However, if
+there are other modifications worth saving, we will go ahead and save the
+directory entry update at the same time.
+
+Similarly, symlink targets are commonly stored in the inode entry
+directly. So once we have stat'ed the symlink, we already have its target
+information in memory. The one caveat is if we used to think an object was
+a file, and it became a directory or symlink, then we will treat it as
+worth saving.
+
+In the case of newly added files, we never have to read their content to
+know that they are different from the basis tree. So saving the updated
+information also won't save a future read.
+
+
+.. vim: ft=rst tw=74 et
diff --git a/doc/developers/documenting-changes.txt b/doc/developers/documenting-changes.txt
new file mode 100644
index 0000000..16e9d0d
--- /dev/null
+++ b/doc/developers/documenting-changes.txt
@@ -0,0 +1,100 @@
+===================
+Documenting Changes
+===================
+
+When you change bzr, please update the relevant documentation for the
+change you made:
+
+Changing existing behavior
+ If the change will break existing command lines, or break
+ interoperability with other versions of Bazaar, mention this in
+ "External Compatibility Breaks" in NEWS, and also in "What's New".
+
+Adding a new feature, function or option
+ Describe this in NEWS, in the user guide, and in the "What's New"
+ document. Consider whether you should also update command help
+ or any help topics.
+
+A new hook or extension point
+ These are also described in NEWS, in the hook documentation, and in
+ "What's New." Even though they might be API-only changes, the fact that
+ they exist may interest users enough to write a new plugin that uses
+ them.
+
+Fixing a bug
+ If the bug has any user-visible impact, describe it in the NEWS file
+ in such a way that users can tell whether the problem they're
+ experiencing is the one that was fixed.
+
+Improving performance
+ Mention this under "improvements" in NEWS, and if it's a notable
+ improvement mention it in "What's New".
+
+Deprecating an API, or adding a new recommended API
+ Mention this in the "API Changes" of NEWS, if it's likely to affect
+ plugin authors. Consider whether you should also update the developer
+ documentation.
+
+Changing the way the test suite works or adding more tests
+ Mention this under "Testing" in NEWS, and update the developer guide
+ to testing.
+
+Purely internal changes
+ If the change has no user-visible impact and is not interesting to
+ plugin developers, it doesn't need to be mentioned in NEWS. If you're
+ setting a new pattern or adding a new abstraction, update the developer
+ docs.
+
+NEWS File
+---------
+
+If you make a user-visible change, please add a note to the NEWS file.
+The description should be written to make sense to someone who's just
+a user of bzr, not a developer: new functions or classes shouldn't be
+mentioned, but new commands, changes in behaviour or fixed nontrivial
+bugs should be listed. See the existing entries for an idea of what
+should be done.
+
+Within each release, entries in the news file should have the most
+user-visible changes first. So the order should be approximately:
+
+* changes to existing behaviour - the highest priority because the
+ user's existing knowledge is incorrect
+* new features - should be brought to their attention
+* bug fixes - may be of interest if the bug was affecting them, and
+ should include the bug number if any
+* major documentation changes, including fixed documentation bugs
+
+People who made significant contributions to each change are listed in
+parenthesis. This can include reporting bugs (particularly with good
+details or reproduction recipes), submitting patches, etc.
+
+To help with merging, NEWS entries should be sorted lexicographically
+within each section.
+
+Commands
+--------
+
+The docstring of a command is used by ``bzr help`` to generate help output
+for the command. The list 'takes_options' attribute on a command is used by
+``bzr help`` to document the options for the command - the command
+docstring does not need to document them. Finally, the '_see_also'
+attribute on a command can be used to reference other related help topics.
+
+API Documentation
+-----------------
+
+Functions, methods, classes and modules should have docstrings
+describing how they are used.
+
+The first line of the docstring should be a self-contained sentence.
+
+For the special case of Command classes, this acts as the user-visible
+documentation shown by the help command.
+
+The docstrings should be formatted as reStructuredText_ (like this
+document), suitable for processing using the epydoc_ tool into HTML
+documentation.
+
+.. _reStructuredText: http://docutils.sourceforge.net/rst.html
+.. _epydoc: http://epydoc.sourceforge.net/
diff --git a/doc/developers/ec2.txt b/doc/developers/ec2.txt
new file mode 100644
index 0000000..6881106
--- /dev/null
+++ b/doc/developers/ec2.txt
@@ -0,0 +1,208 @@
+=========================
+Bazaar Windows EC2 Server
+=========================
+
+We have an Amazon EC2 virtual machine called Desolation_ for
+building Windows packages and general testing on Windows. As of
+2009-02-19, this is just experimental and this is a draft specification,
+but we aim to use it for the production Windows installer build of 1.13 in
+March.
+
+See also:
+
+* `Bazaar Developer Documentation Catalog <index.html>`_.
+
+
+.. _Desolation: http://en.wikipedia.org/wiki/Desolation_Island
+
+
+Goals
+=====
+
+* The instance is only running (and incurring charges) when it's needed
+ for testing or packaging.
+
+* It can be started or stopped by anyone on the team using a
+ straightforward script.
+
+* Multiple people can get into the same instance at the same time, e.g.
+ if one person needs to pass work on to some one else.
+
+* We keep snapshot of the OS and tool chain so that we can roll back if
+ we need to.
+
+* bzr branches and similar information are kept on stable storage that
+ survives rollbacks of the OS state, and that can be backed up.
+
+Later on we may try automated Windows testing in a similar setup.
+
+
+Approach
+========
+
+The working disk and the AMI images are stored in one person's account for
+billing purposes.
+
+Ideally we want to give other people access to run this machine without
+giving full access to the account. I'm not sure if that's feasible. If
+it's not, we might need to allow people to launch the image within their
+own account; this may be problematic if the shared volume is already in
+use by someone else.
+
+I don't think it's possible to have an EBS that's shared across accounts,
+and they can't be attached to multiple running instances. So for now it's
+probably best to just ignore the concept and store the working data on the
+instance's local storage, and to copy things up e.g. to Launchpad as
+required.
+
+On this machine, ``C:`` should be used only for the Windows system files,
+``D:`` for installed programs and working directories, and other drive
+letters can be used later for mounting EBS storage if desired.
+
+Through ``ec2-modify-image-attribute`` we can allow nominated users to
+access an existing image. We need to have their AWS opaque ID.
+
+Through ``ec2-bundle-image`` we can make a new snapshot at any point,
+which will be stored into the current user's S3 account.
+
+We'll (probably) have one shared account for running builds which is also
+an administrator for ease of installing software.
+
+You do need to have an RSA keypair to get the initial password for a
+Windows machine, even though you can't use it to log in later.
+``ec2-get-password`` takes the full path to the private key to obtain the
+password from Amazon, and ``ec2-add-keypair`` creates a named keypair at
+Amazon and returns the private path. One keypair is all that is needed.
+This is distinct from the account identifier - likely due to the different
+toolchains in use (the keypairs are used for unix SSH keys, and I (Robert)
+suspect a rather unix friendly core at Amazon).
+Once a custom image is made with a saved password, you can skip using
+``ec2-get-password`` (which is only needed for Windows anyway).
+
+It would be nice if rdesktop could use private key authentication but
+apparently not.
+
+Should check how the Launchpad ec2test scripts work.
+
+
+
+Procedures
+==========
+
+Preparation
+-----------
+
+* Be in the bzr core team. If you are interested in helping with
+ Windows packaging, testing or development just ask.
+
+* Install the
+ `Amazon EC2 API tools`_ (needs-packaging `bug 330930`_)
+
+* Create an Amazon Web Services account, sign up for S3 and EC2, and do
+ the various steps to create authentication devices.
+
+* Create a private key and certificate for yourself.
+ Check these environment variables are set and exported, e.g. by setting
+ them in the file ``~/.aws``. Make sure the files are private.::
+
+ export EC2_PRIVATE_KEY=~/.ec2/pk-XXXXXX.pem
+ export EC2_CERT=~/.ec2/cert-XXXXXX.pem
+ export EC2_HOME=~/build/ec2-api-tools-1.3-30349
+ export AWS_SECRET_ACCESS_KEY=XXXXXXXXX
+ export AWS_ACCESS_KEY_ID=XXXXXXXXXXX
+ export EC2_KEYPAIR_NAME=XXXXXXXXX
+ export PATH=$PATH:$EC2_HOME/bin
+ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
+ ssh-add ~/.ec2/id_rsa
+
+ You can now '. ~/.aws' to get the ec2 commands available.
+
+* (Unix images only) run ec2-add-keypair SOMENAME, e.g. 'bzr'. Put the
+ result (minus the first line) somewhere like ~/.ec2/id_rsa and chmod go-rw.
+
+* A useful Unix image is `ami-bdfe19d4`_, Eric Hammonds 64-bit Ubuntu image.
+
+* Install the rdesktop client, to actually access the machine.
+
+* Possibly read some of the `EC2 documentation`_ for background.
+
+.. _`bug 330930`: https://bugs.launchpad.net/ubuntu/+bug/330930
+.. _`Amazon EC2 API tools`:
+ http://developer.amazonwebservices.com/connect/entry.jspa?externalID=368&categoryID=88
+.. _`EC2 documentation`: http://aws.amazon.com/
+.. _`ami-bdfe19d4`:
+ http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1762&categoryID=101
+
+* Create a security group for your that allows rdesktop access and icmp with::
+
+ ec2-add-group desolation-group -d 'bzr win32 build machine'
+ ec2-authorize desolation-group -p 3389 -s 1.2.3.4/32
+ ec2-authorize desolation-group -t -1:-1 -P icmp
+
+ Add your public IP there. You can repeat that command to allow others
+ in.
+
+
+To start up an instance
+-----------------------
+
+1. Get the right AMI image ID from another developer.
+
+1. Start the instance::
+
+ ec2-run-instances $image_id -g desolation-group
+
+ This will print out some information including the image id, something
+ like ``i-31a74258``.
+
+1. Actually starting the machine will take a few minutes. Once it's in
+ the *running* state, get the machine's public IP with ::
+
+ ec2-describe-instances
+
+1. and then connect ::
+
+ rdesktop -g 1200x850 -u Administrator $machine_ip
+
+Don't forget to shut it down when you're done, and check with
+``ec2-describe-instances`` that it did terminate.
+
+
+To save a system snapshot as an image
+-------------------------------------
+
+1. Bundle the current state. *Doing this will reboot the machine.*
+ You need to choose a unique s3 bucket name,
+ typically based on a domain or email address, which can contain
+ any number of images. You also need a name unique within the bucket
+ for this image, like ``desolation-vs2008-20090219``. And finally
+ it needs your AWS S3 access key and secret key, which should be set in
+ ``~/.aws``::
+
+ ec2-bundle-instance -b ec2.sourcefrog.net \
+ -p desolation-vs2008-2009021 \
+ -o "$AWS_ACCESS_KEY_ID" \
+ -w "$AWS_SECRET_ACCESS_KEY"
+
+1. This will take several minutes: You can check progress with ::
+
+ ec2-describe-bundle-tasks
+
+1. Register the files as an image, e.g.::
+
+ ec2-register ec2.sourcefrog.net/desolation-vs2008-2009021
+
+ This will give you an AMI id for the image.
+
+1. Give access to other team members identified by their Amazon account id::
+
+ ec2-modify-image-attributes $ami_id -l -a 123412341234
+
+
+Management console (useful!)
+----------------------------
+
+https://console.aws.amazon.com/ec2/home
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/feature-flags.txt b/doc/developers/feature-flags.txt
new file mode 100644
index 0000000..e1f73d8
--- /dev/null
+++ b/doc/developers/feature-flags.txt
@@ -0,0 +1,150 @@
+Format feature flags
+====================
+
+.. contents::
+
+Rationale
+---------
+
+In the past when new features were added that required a change to the
+on-disk format, Bazaar has introduced a new format (in other words,
+a different string in .bzr/branch-format, .bzr/branch/format,
+.bzr/repository/format or .bzr/checkout/format). The main reason for this
+was that it made old versions of Bazaar give a sensible error message
+when they encountered on-disk data that they could not understand.
+
+There are also several disadvantages to such an approach:
+
+ * Once upgraded, a newer version of Bazaar is required to access the data
+ (it is often possible to downgrade the format later on)
+
+ * Upgrading requires an explicit action by the user. It could be
+ done automatically, but then accessing a repository with a newer version
+ of Bazaar might accidentally render it inaccessible by older.
+
+Not all format changes should necessarily render the data inaccessible
+to older versions of Bazaar.
+
+There are also various plugins that store extra metadata in the Bazaar
+version control directory. They currently have no way of indicating that
+e.g. writing to the repository requires a particular plugin to be installed
+(so the metadata can be kept up to date, for example).
+
+Proposed approach
+-----------------
+
+To allow for more granular changes to the format, this spec proposes
+to add feature flags to the Bazaar formats, indicating
+what kind of data is present in that repository. Each feature has
+a name and some sort of indicator that tells the bzr client its
+"necessity" - optional, required, ...
+
+bzr clients would be able to open data with features that are
+set as "optional" but that they do not support. If there are features
+that aren't supported which are marked "required" in the repository they
+would refuse to open the repository.
+
+Various kinds of metadata, e.g. ones that are generated from the
+repository itself and can be discarded without losing data (caches)
+would fall in the optional category.
+
+Feature necessity
+-----------------
+
+The initial implementation will feature the following two possible
+settings for feature ``necessity``. Any format necessity that can't
+be understood should be interpreted as "required", and an appropriate
+warning printed.
+
+ - optional: the feature is present, but writing/reading of the
+ repository/branch/checkout is possible without support for the
+ feature. Useful for things like caches (e.g. bzr-search index,
+ annotate cache)
+ - required: read and write access is only possible if the feature
+ is supported. Useful for things like nested trees.
+
+In the future, we might add more values for necessity. Older
+versions of bzr treat unknown necessities as "required". Some likely
+candidates for new necessities that might be added in the future:
+
+ - read-optional: read access is possible if the feature is not supported,
+ but write access requires it
+ - client-read-optional: directly writing to the object requires
+ the feature, but reading or writing through an intermediary (such as
+ a HPSS server) doesn't.
+
+Format changes
+--------------
+
+The feature information would be included in the appropriate ``format`` file
+(``.bzr/branch-format``, ``.bzr/branch/format``, ``.bzr/repository/format`` or
+``.bzr/checkout/format``). This file currently always contains a single
+line with the format name. Older versions of bzr read the full file.
+
+By using the other lines for feature information it is possible to add feature
+flags in a backwards compatible manner; older clients will simply fail to open
+repositories with feature flags set, giving a unknown format error.
+
+The other advantage of doing this is that we don't need any additional
+roundtrips when opening a remote format. An example .bzr/repository/format
+file could then look like this::
+
+ Bazaar repository format 2a (needs bzr 1.16 or later)
+ optional git
+ optional search
+ optional tiplog
+ required nested-trees
+
+In other words, this is a "2a" bzr format which also stores a cache of
+Git Tree/Commit objects, a bzr-search index, and a reflog. It also contains
+revisions with nested trees.
+
+API Changes
+-----------
+
+Class methods will be added to ``BzrFormat`` to allow registering
+and unregistering the presence of particular features.
+
+ * BzrFormat.register_feature(name)
+ * BzrFormat.unregister_feature(name)
+
+The namespace for features is global. It is assumed
+that the plugin that provides the feature X provides that feature
+in all objects that it is relevant for. For example, if a plugin
+provides the ``nested-trees`` feature, it is assumed to support
+that in both working trees and repositories. If this is not the case,
+it should use a different feature name for the working tree support
+and the repository support.
+
+BzrFormat is inherited by ``BranchFormatMetaDir``, ``BzrDirFormat``,
+``RepositoryFormatMetaDir`` and ``WorkingTreeFormatMetaDir``.
+
+Upon opening, BzrFormat will be responsible for checking that the
+required features are present. lock_write will raise an exception
+when there is an unsupported mandatory feature required for write access.
+
+Methods will also be added to BzrFormat to allow plugins, etc,
+to check whether a feature is present and adding new features:
+
+ * BzrFormat.features.set(name, necessity)
+ * BzrFormat.features.get(name) -> necessity
+
+Enabling features
+-----------------
+
+Features are enabled through the ``update_feature_flags`` method on
+``Repository``, ``Branch``, ``WorkingTree`` and ``BzrDir``.
+
+These methods are called by whatever needs to enable features.
+When they do that is up to them - e.g. bzr-search would enable its
+feature when ``bzr index`` is first run.
+
+See also
+--------
+
+Mercurial has a similar feature, using its `.hg/requires`_ file.
+
+.. _.hg/requires: http://mercurial.selenic.com/wiki/RequiresFile
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/fetch.txt b/doc/developers/fetch.txt
new file mode 100644
index 0000000..ac984b6
--- /dev/null
+++ b/doc/developers/fetch.txt
@@ -0,0 +1,171 @@
+=============
+Fetching data
+=============
+
+Overview of a fetch
+===================
+
+Inside bzr, a typical fetch happens like this:
+
+* a user runs a command like ``bzr branch`` or ``bzr pull``
+
+* ``Repository.fetch`` is called (by a higher-level method such as
+ ``ControlDir.sprout``, ``Branch.fetch``, etc).
+
+* An ``InterRepository`` object is created. The exact implementation of
+ ``InterRepository`` chosen depends on the format/capabilities of the
+ source and target repos.
+
+* The source and target repositories are compared to determine which data
+ needs to be transferred.
+
+* The repository data is copied. Often this is done by creating a
+ ``StreamSource`` and ``StreamSink`` from the source and target
+ repositories and feeding the stream from the source into the sink, but
+ some ``InterRepository`` implementations do differently.
+
+
+How objects to be transferred are determined
+============================================
+
+See ``InterRepository._walk_to_common_revisions``. The basic idea is to
+do a breadth-first search in the source repository's revision graph
+(starting from the head or heads the caller asked for), and look in the
+target repository to see if those revisions are already present.
+Eventually this will find the common ancestors in both graphs, and thus
+the set of revisions to be copied has been identified.
+
+All inventories for the copied revisions need to be present (and all
+parent inventories at the stacking boundary too, to support stacking).
+
+All texts versions introduced by those inventories need to be transferred
+(but see also stacking constraints).
+
+Fetch specs
+===========
+
+The most ``fetch`` methods accept a ``fetch_spec`` parameter. This is how
+the caller controls what is fetched: e.g. all revisions for a given head
+(that aren't already present in the target), the full ancestry for one or
+more heads, or even the full contents of the source repository.
+
+The ``fetch_spec`` parameter is an object that implements the interface
+defined by ``AbstractSearchResult`` in ``bzrlib.graph``. It describes
+which keys should be fetched. Current implementations are
+``SearchResult``, ``PendingAncestryResult``, ``EmptySearchResult``, and
+``EverythingResult``. Some have options controlling if missing revisions
+cause errors or not, etc.
+
+There are also some “search” objects, which can be used to conveniently
+construct a search result for common cases: ``EverythingNotInOther`` and
+``NotInOtherForRevs``. They provide an ``execute`` method that performs
+the search and returns a search result.
+
+Also, ``Graph._make_breadth_first_searcher`` returns an object with a
+``get_result`` method that returns a search result.
+
+
+Streams
+=======
+
+A **stream** is an iterable of (substream type, substream) pairs.
+The **substream type** is a ``str`` that will be one of ``texts``,
+``inventories``, ``inventory-deltas``, ``chk_bytes``, ``revisions`` or
+``signatures``. A **substream** is a record stream. The format of those
+records depends on the repository format being streamed, except for
+``inventory-deltas`` records which are format-independent.
+
+A stream source can be constructed with ``repo._get_source(to_format)``,
+and it provides a ``get_stream(search)`` method (among others). A stream
+sink can be constructed with ``repo._get_sink()``, and provides an
+``insert_stream(stream, src_format, resume_tokens)`` method (among
+others).
+
+
+Stacking constraints
+====================
+
+**In short the rule is:** "repositories must hold revisions' parent
+inventories and their new texts (or else all texts for those revisions)."
+
+This is sometimes called "the stacking invariant."
+
+Why that rule?
+--------------
+
+A stacked repository needs to be capable of generating a complete stream
+for the revisions it does hold without access to its fallback
+repositories [#]_. "Complete" here means that the stream for a revision (or
+set of revisions) can be inserted into a repository that already contains
+the parent(s) of that revision, and that repository will have a fully
+usable copy of that revision: a working tree can be built for that
+revision, etc.
+
+Assuming for a moment the stream has the necessary inventory, signature
+and CHK records to have a usable revision, what texts are required to have
+a usable revision? The simple way to satisfy the requirement is to have
+*every* text for every revision at the stacking boundary. Thus the
+revisions at the stacking boundary and all their descendants have their
+texts present and so can be fully reconstructed. But this is expensive:
+it implies each stacked repository much contain *O(tree)* data even for a
+single revision of a 1-line change, and also implies transferring
+*O(tree)* data to fetch that revision.
+
+Because the goal is a usable revision *when added to a repository with the
+parent revision(s)* most of those texts will be redundant. The minimal
+set that is needed is just those texts that are new in the revisions in
+our repository. However, we need enough inventory data to be able to
+determine that set of texts. So to make this possible every revision must
+have its parent inventories present so that the inventory delta between
+revisions can be calculated, and of course the CHK pages associated with
+that delta. In fact the entire inventory does not need to be present,
+just enough of it to find the delta (assuming a repository format, like
+2a, that allows only part of an inventory to be stored). Thus the stacked
+repository can contain only *O(changes)* data [#]_ and still deliver
+complete streams of that data.
+
+What about revisions at the stacking boundary with more than one parent?
+All of the parent inventories must be present, as a client may ask for a
+stream up to any parent, not just the left-hand parent. If any parent is
+absent then all texts must be present instead. Otherwise there will be
+the strange situation where some fetches of a revision will succeed and
+others fail depending the precise details of the fetch.
+
+Implications for fetching
+-------------------------
+
+Fetches must retrieve the records necessary to satisfy that rule. The
+stream source will attempt to send the necessary records, and the stream
+sink will check for any missing records and make a second fetch for just
+those missing records before committing the write group.
+
+Our repository implementations check this constraint is satisfied before
+committing a write group, to prevent a bad stream from creating a corrupt
+repository. So a fetch from a bad source (e.g. a damaged repository, or a
+buggy foreign-format import) may trigger ``BzrCheckError`` during
+``commit_write_group``.
+
+To fetch from a stacked repository via a smart server, the smart client:
+
+* first fetches a stream of as many of the requested revisions as possible
+ from the initial repository,
+* then while there are still missing revisions and untried fallback
+ repositories fetches the outstanding revisions from the next fallback
+ until either all revisions have been found (success) or the list of
+ fallbacks has been exhausted (failure).
+
+
+.. [#] This is not just a theoretical concern. The smart server always
+ opens repositories without opening fallbacks, as it cannot assume it
+ can access the fallbacks that the client can.
+
+.. [#] Actually *O(changes)* isn't quite right in practice. In the
+ current implementation the fulltext of a changed file must be
+ transferred, not just a delta, so a 1-line change to a 10MB file will
+ still transfer 10MB of text data. This is because current formats
+ require records' compression parents to be present in the same
+ repository.
+
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/gc.txt b/doc/developers/gc.txt
new file mode 100644
index 0000000..c933fc2
--- /dev/null
+++ b/doc/developers/gc.txt
@@ -0,0 +1,26 @@
+Garbage Collection
+==================
+
+Garbage collection is used to remove data from a repository that is no longer referenced.
+
+Generally this involves locking the repository and scanning all its branches
+then generating a new repository with less data.
+
+Least work we can hope to perform
+---------------------------------
+
+* Read all branches to get initial references - tips + tags.
+* Read through the revision graph to find unreferenced revisions. A cheap HEADS
+ list might help here by allowing comparison of the initial references to the
+ HEADS - any unreferenced head is garbage.
+* Walk out via inventory deltas to get the full set of texts and signatures to preserve.
+* Copy to a new repository
+* Bait and switch back to the original
+* Remove the old repository.
+
+A possibility to reduce this would be to have a set of grouped 'known garbage
+free' data - 'ancient history' which can be preserved in total should its HEADS
+be fully referenced - and where the HEADS list is deliberate cheap (e.g. at the
+top of some index).
+
+possibly - null data in place without saving size.
diff --git a/doc/developers/groupcompress-design.txt b/doc/developers/groupcompress-design.txt
new file mode 100644
index 0000000..629b761
--- /dev/null
+++ b/doc/developers/groupcompress-design.txt
@@ -0,0 +1,115 @@
+This document contains notes about the design for groupcompress, replacement
+VersionedFiles store for use in pack based repositories. The goal is to provide
+fast, history bounded text extraction.
+
+Overview
+++++++++
+
+The goal: Much tighter compression, maintained automatically. Considerations
+to weigh: The minimum IO to reconstruct a text with no other repository
+involved; The number of index lookups to plan a reconstruction. The minimum
+IO to reconstruct a text with another repositories assistance (affects
+network IO for fetch, which impacts incremental pulls and shallow branch
+operations).
+
+Current approach
+================
+
+Each delta is individually compressed against another text, and then entropy
+compressed. We index the pointers between these deltas.
+
+Solo reconstruction: Plan a readv via the index, read the deltas in forward
+IO, apply each delta. Total IO: sum(deltas) + deltacount*index overhead.
+Fetch/stacked reconstruction: Plan a readv via the index, using local basis
+texts where possible. Then readv locally and remote and apply deltas. Total IO
+as for solo reconstruction.
+
+Things to keep
+==============
+
+Reasonable sizes 'amount read' from remote machines to reconstruct an arbitrary
+text: Reading 5MB for a 100K plain text is not a good trade off. Reading (say)
+500K is probably acceptable. Reading ~100K is ideal. However, it's likely that
+some texts (e.g NEWS versions) can be stored for nearly-no space at all if we
+are willing to have unbounded IO. Profiling to set a good heuristic will be
+important. Also allowing users to choose to optimise for a server environment
+may make sense: paying more local IO for less compact storage may be useful.
+
+Things to remove
+================
+
+Index scatter gather IO. Doing hundreds or thousands of index lookups is very
+expensive, and doing that per file just adds insult to injury.
+
+Partioned compression amongst files.
+
+Scatter gather IO when reconstructing texts: linear forward IO is better.
+
+Thoughts
+========
+
+Merges combine texts from multiple versions to create a new version. Deltas
+add new text to existing files and remove some text from the same. Getting
+high compression means reading some base and then a chain of deltas (could
+be a tree) to gain access to the thing that the final delta was made against,
+and that delta. Rather than composing all these deltas, we can just just
+perform the final diff against the base text and the serialised invidual
+deltas. If the diff algorithm can reuse out of order lines from previous
+texts (e.g. storing AB -> BA as pointers rather than delete and add, then
+the presence of any previously stored line in a single chain can be reused.
+One such diff algorithm is xdelta, another reasonable one to consider is
+plain old zlib or lzma. We could also use bzip2. One advantage of using
+a generic compression engine is less python code. One advantage of
+preprocessing line based deltas is that we reduce the window size for the
+text repeated within lines, and that will help compression by a simple
+entropy compressor as a post processor.
+lzma appears fantastic at compression - 420MB of NEWS files down to 200KB.
+so window size appears to be a key determiner for efficiency.
+
+Delta strategy
+++++++++++++++
+
+Very big objects - no delta. I plan to kick this in at 5MB initially, but
+once the codebase is up and running, we can tweak this to
+
+Very small objects - no delta? If they are combined with a larger zlib object
+why not? (Answer: because zlib's window is really small)
+
+Other objects - group by fileid (gives related texts a chance, though using a
+file name would be better long term as e.g. COPYING and COPYING from different
+projects could combine). Then by reverse topological graph(as this places more
+recent texts at the front of a chain). Alternatively, group by size, though
+that should not matter with a large enough window.
+Finally, delta the texts against the current output of the compressor. This is
+essentially a somewhat typed form of sliding window dictionary compression. An
+alternative implementation would be to just use zlib, or lzma, or bzip2
+directory.
+
+Unfortunately, just using entropy compression forces a lot of data to be output
+by the decompressor - e.g. 420MB in the NEWS sample corpus. When we only want
+a single 55K text thats inefficient. (An initial test took several seconds with
+lzma.)
+
+The fastest to implement approach is probably just 'diff output to date and add
+to entropy compressor'. This should produce reasonable results. As delta
+chain length is not a concern (only one delta to apply ever), we can simply
+cap the chain when the total read size becomes unreasonable. Given older texts
+are smaller we probably want some weighted factor of plaintext size.
+
+In this approach, a single entropy compressed region is read as a unit, giving
+the lower bound for IO (and how much to read is an open question - what byte
+offset of compressed data is sufficient to ensue that the delta-stream contents
+we need are reconstructable. Flushing, while possible, degrades compression(and
+adds overhead - we'd be paying 4 bytes per record guaranteed). Again - tests
+will be needed.
+
+A nice possibility is to output mpdiff compatible records, which might enable
+some code reuse. This is more work than just diff (current_out, new_text), so
+can wait for the concept to be proven.
+
+Implementation Strategy
++++++++++++++++++++++++
+
+Bring up a VersionedFiles object that implements this, then stuff it into a
+repository format. zlib as a starting compressor, though bzip2 will probably
+do a good job.
diff --git a/doc/developers/implementation-notes.txt b/doc/developers/implementation-notes.txt
new file mode 100644
index 0000000..28f1ab1
--- /dev/null
+++ b/doc/developers/implementation-notes.txt
@@ -0,0 +1,28 @@
+Implementation notes
+====================
+
+.. toctree::
+ :hidden:
+
+ btree_index_prefetch
+ last-modified
+ content-filtering
+ lca_tree_merging
+
+
+* `BTree Index Prefetch <btree_index_prefetch.html>`_ |--| How bzr decides
+ to pre-read extra nodes in the btree index.
+
+* `Computing last_modified values <last-modified.html>`_ for inventory
+ entries
+
+* `Content filtering <content-filtering.html>`_
+
+* `LCA Tree Merging <lca_tree_merging.html>`_ |--| Merging tree-shape when
+ there is not a single unique ancestor (criss-cross merge).
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/improved_chk_index.txt b/doc/developers/improved_chk_index.txt
new file mode 100644
index 0000000..7d86b39
--- /dev/null
+++ b/doc/developers/improved_chk_index.txt
@@ -0,0 +1,474 @@
+===================
+CHK Optimized index
+===================
+
+Our current btree style index is nice as a general index, but it is not optimal
+for Content-Hash-Key based content. With CHK, the keys themselves are hashes,
+which means they are randomly distributed (similar keys do not refer to
+similar content), and they do not compress well. However, we can create an
+index which takes advantage of these abilites, rather than suffering from
+them. Even further, there are specific advantages provided by
+``groupcompress``, because of how individual items are clustered together.
+
+Btree indexes also rely on zlib compression, in order to get their compact
+size, and further has to try hard to fit things into a compressed 4k page.
+When the key is a sha1 hash, we would not expect to get better than 20bytes
+per key, which is the same size as the binary representation of the hash. This
+means we could write an index format that gets approximately the same on-disk
+size, without having the overhead of ``zlib.decompress``. Some thought would
+still need to be put into how to efficiently access these records from remote.
+
+
+Required information
+====================
+For a given groupcompress record, we need to know the offset and length of the
+compressed group in the .pack file, and the start and end of the content inside
+the uncompressed group. The absolute minimum is slightly less, but this is a
+good starting point. The other thing to consider, is that for 1M revisions and
+1M files, we'll probably have 10-20M CHK pages, so we want to make sure we
+have an index that can scale up efficiently.
+
+1. A compressed sha hash is 20-bytes
+
+2. Pack files can be > 4GB, we could use an 8-byte (64-bit) pointer, or we
+ could store a 5-byte pointer for a cap at 1TB. 8-bytes still seems like
+ overkill, even if it is the natural next size up.
+
+3. An individual group would never be longer than 2^32, but they will often
+ be bigger than 2^16. 3 bytes for length (16MB) would be the minimum safe
+ length, and may not be safe if we expand groups for large content (like ISOs).
+ So probably 4-bytes for group length is necessary.
+
+4. A given start offset has to fit in the group, so another 4-bytes.
+
+5. Uncompressed length of record is based on original size, so 4-bytes is
+ expected as well.
+
+6. That leaves us with 20+8+4+4+4 = 40 bytes per record. At the moment, btree
+ compression gives us closer to 38.5 bytes per record. We don't have perfect
+ compression, but we also don't have >4GB pack files (and if we did, the first
+ 4GB are all under then 2^32 barrier :).
+
+If we wanted to go back to the ''minimal'' amount of data that we would need to
+store.
+
+1. 8 bytes of a sha hash are generally going to be more than enough to fully
+ determine the entry (see `Partial hash`_). We could support some amount of
+ collision in an index record, in exchange for resolving it inside the
+ content. At least in theory, we don't *have* to record the whole 20-bytes
+ for the sha1 hash. (8-bytes gives us less than 1 in 1000 chance of
+ a single collision for 10M nodes in an index)
+
+2. We could record the start and length of each group in a separate location,
+ and then have each record reference the group by an 'offset'. This is because
+ we expect to have many records in the same group (something like 10k or so,
+ though we've fit >64k under some circumstances). At a minimum, we have one
+ record per group so we have to store at least one reference anyway. So the
+ maximum overhead is just the size and cost of the dereference (and normally
+ will be much much better than that.)
+
+3. If a group reference is an 8-byte start, and a 4-byte length, and we have
+ 10M keys, but get at least 1k records per group, then we would have 10k
+ groups. So we would need 120kB to record all the group offsets, and then
+ each individual record would only need a 2-byte group number, rather than a
+ 12-byte reference. We could be safe with a 4-byte group number, but if
+ each group is ~1MB, 64k groups is 64GB. We can start with 2-byte, but leave
+ room in the header info to indicate if we have more than 64k group entries.
+ Also, current grouping creates groups of 4MB each, which would make it
+ 256GB, to create 64k groups. And our current chk pages compress down to
+ less than 100 bytes each (average is closer to 40 bytes), which for 256GB
+ of raw data, would amount to 2.7 billion CHK records. (This will change if
+ we start to use CHK for text records, as they do not compress down as
+ small.) Using 100 bytes per 10M chk records, we have 1GB of compressed chk
+ data, split into 4MB groups or 250 total groups. Still << 64k groups.
+ Conversions could create 1 chk record at a time, creating a group for each,
+ but they would be foolish to not commit a write group after 10k revisions
+ (assuming 6 CHK pages each).
+
+4. We want to know the start-and-length of a record in the decompressed
+ stream. This could actually be moved into a mini-index inside the group
+ itself. Initial testing showed that storing an expanded "key =>
+ start,offset" consumed a considerable amount of compressed space. (about
+ 30% of final size was just these internal indices.) However, we could move
+ to a pure "record 1 is at location 10-20", and then our external index
+ would just have a single 'group entry number'.
+
+ There are other internal forces that would give a natural cap of 64k
+ entries per group. So without much loss of generality, we could probably get
+ away with a 2-byte 'group entry' number. (which then generates an 8-byte
+ offset + endpoint as a header in the group itself.)
+
+5. So for 1M keys, an ideal chk+group index would be:
+
+ a. 6-byte hash prefix
+
+ b. 2-byte group number
+
+ c. 2-byte entry in group number
+
+ d. a separate lookup of 12-byte group number to offset + length
+
+ e. a variable width mini-index that splits X bits of the key. (to maintain
+ small keys, low chance of collision, this is *not* redundant with the
+ value stored in (a)) This should then dereference into a location in
+ the index. This should probably be a 4-byte reference. It is unlikely,
+ but possible, to have an index >16MB. With an 10-byte entry, it only
+ takes 1.6M chk nodes to do so. At the smallest end, this will probably
+ be a 256-way (8-bits) fan out, at the high end it could go up to
+ 64k-way (16-bits) or maybe even 1M-way (20-bits). (64k-way should
+ handle up to 5-16M nodes and still allow a cheap <4k read to find the
+ final entry.)
+
+So the max size for the optimal groupcompress+chk index with 10M entries would be::
+
+ 10 * 10M (entries) + 64k * 12 (group) + 64k * 4 (mini index) = 101 MiB
+
+So 101MiB which breaks down as 100MiB for the actual entries, 0.75MiB for the
+group records, and 0.25MiB for the mini index.
+
+1. Looking up a key would involve:
+
+ a. Read ``XX`` bytes to get the header, and various config for the index.
+ Such as length of the group records, length of mini index, etc.
+
+ b. Find the offset in the mini index for the first YY bits of the key. Read
+ the 4 byte pointer stored at that location (which may already be in the
+ first content if we pre-read a minimum size.)
+
+ c. Jump to the location indicated, and read enough bytes to find the
+ correct 12-byte record. The mini-index only indicates the start of
+ records that start with the given prefix. A 64k-way index resolves 10MB
+ records down to 160 possibilities. So at 12 bytes each, to read all would
+ cost 1920 bytes to be read.
+
+ d. Determine the offset for the group entry, which is the known ``start of
+ groups`` location + 12B*offset number. Read its 12-byte record.
+
+ e. Switch to the .pack file, and read the group header to determine where in
+ the stream the given record exists. At this point, you have enough
+ information to read the entire group block. For local ops, you could
+ only read enough to get the header, and then only read enough to
+ decompress just the content you want to get at.
+
+ Using an offset, you also don't need to decode the entire group header.
+ If we assume that things are stored in fixed-size records, you can jump
+ to exactly the entry that you care about, and read its 8-byte
+ (start,length in uncompressed) info. If we wanted more redundancy we
+ could store the 20-byte hash, but the content can verify itself.
+
+ f. If the size of these mini headers becomes critical (8 bytes per record
+ is 8% overhead for 100 byte records), we could also compress this mini
+ header. Changing the number of bytes per entry is unlikely to be
+ efficient, because groups standardize on 4MiB wide, which is >>64KiB for
+ a 2-byte offset, 3-bytes would be enough as long as we never store an
+ ISO as a single entry in the content. Variable width also isn't a big
+ win, since base-128 hits 4-bytes at just 2MiB.
+
+ For minimum size without compression, we could only store the 4-byte
+ length of each node. Then to compute the offset, you have to sum all
+ previous nodes. We require <64k nodes in a group, so it is up to 256KiB
+ for this header, but we would lose partial reads. This should still be
+ cheap in compiled code (needs tests, as you can't do partial info), and
+ would also have the advantage that fixed width would be highly
+ compressible itself. (Most nodes are going to have a length that fits
+ 1-2 bytes.)
+
+ An alternative form would be to use the base-128 encoding. (If the MSB
+ is set, then the next byte needs to be added to the current value
+ shifted by 7*n bits.) This encodes 4GiB in 5 bytes, but stores 127B in 1
+ byte, and 2MiB in 3 bytes. If we only stored 64k entries in a 4 MiB
+ group, the average size can only be 64B, which fits in a single byte
+ length, so 64KiB for this header, or only 1.5% overhead. We also don't
+ have to compute the offset of *all* nodes, just the ones before the one
+ we want, which is the similar to what we have to do to get the actual
+ content out.
+
+
+Partial Hash
+============
+The size of the index is dominated by the individual entries (the 1M records).
+Saving 1 byte there saves 1MB overall, which is the same as the group entries
+and mini index combined. If we can change the index so that it can handle
+collisions gracefully (have multiple records for a given collision), then we
+can shrink the number of bytes we need overall. Also, if we aren't going to
+put the full 20-bytes into the index, then some form of graceful handling of
+collisions is recommended anyway.
+
+The current structure does this just fine, in that the mini-index dereferences
+you to a "list" of records that start with that prefix. It is assumed that
+those would be sorted, but we could easily have multiple records. To resolve
+the exact record, you can read both records, and compute the sha1 to decide
+between them. This has performance implications, as you are now decoding 2x
+the records to get at one.
+
+The chance of ``n`` texts colliding with a hash space of ``H`` is generally
+given as::
+
+ 1 - e ^(-n^2 / 2 H)
+
+Or if you use ``H = 2^h``, where ``h`` is the number of bits::
+
+ 1 - e ^(-n^2 / 2^(h+1))
+
+For 1M keys and 4-bytes (32-bit), the chance of collision is for all intents
+and purposes 100%. Rewriting the equation to give the number of bits (``h``)
+needed versus the number of entries (``n``) and the desired collision rate
+(``epsilon``)::
+
+ h = log_2(-n^2 / ln(1-epsilon)) - 1
+
+The denominator ``ln(1-epsilon)`` == ``-epsilon``` for small values (even @0.1
+== -0.105, and we are assuming we want a much lower chance of collision than
+10%). So we have::
+
+ h = log_2(n^2/epsilon) - 1 = 2 log_2(n) - log_2(epsilon) - 1
+
+Given that ``epsilon`` will often be very small and ``n`` very large, it can
+be more convenient to transform it into ``epsilon = 10^-E`` and ``n = 10^N``,
+which gives us::
+
+ h = 2 * log_2(10^N) - 2 log_2(10^-E) - 1
+ h = log_2(10) (2N + E) - 1
+ h ~ 3.3 (2N + E) - 1
+
+Or if we use number of bytes ``h = 8H``::
+
+ H ~ 0.4 (2N + E)
+
+This actually has some nice understanding to be had. For every order of
+magnitude we want to increase the number of keys (at the same chance of
+collision), we need ~1 byte (0.8), for every two orders of magnitude we want
+to reduce the chance of collision we need the same extra bytes. So with 8
+bytes, you can have 20 orders of magnitude to work with, 10^10 keys, with
+guaranteed collision, or 10 keys with 10^-20 chance of collision.
+
+Putting this in a different form, we could make ``epsilon == 1/n``. This gives
+us an interesting simplified form::
+
+ h = log_2(n^3) - 1 = 3 log_2(n) - 1
+
+writing ``n`` as ``10^N``, and ``H=8h``::
+
+ h = 3 N log_2(10) - 1 =~ 10 N - 1
+ H ~ 1.25 N
+
+So to have a one in a million chance of collision using 1 million keys, you
+need ~59 bits, or slightly more than 7 bytes. For 10 million keys and a one in
+10 million chance of any of them colliding, you can use 9 (8.6) bytes. With 10
+bytes, we have a one in a 100M chance of getting a collision in 100M keys
+(substituting back, the original equation says the chance of collision is 4e-9
+for 100M keys when using 10 bytes.)
+
+Given that the only cost for a collision is reading a second page and ensuring
+the sha hash actually matches we could actually use a fairly "high" collision
+rate. A chance of 1 in 1000 that you will collide in an index with 1M keys is
+certainly acceptible. (note that isn't 1 in 1000 of those keys will be a
+collision, but 1 in 1000 that you will have a *single* collision). Using a
+collision chance of 10^-3, and number of keys 10^6, means we need (12+3)*0.4 =
+6 bytes. For 10M keys, you need (14+3)*0.4 = 6.8 aka 7. We get that extra byte
+from the ``mini-index``. In an index with a lot of keys, you want a bigger
+fan-out up front anyway, which gives you more bytes consumed and extends your
+effective key width.
+
+Also taking one more look at ``H ~ 0.4 (2N + E)``, you can rearrange and
+consider that for every order of magnitude more keys you insert, your chance
+for collision goes up by 2 orders of magnitude. But for 100M keys, 8 bytes
+gives you a 1 in 10,000 chance of collision, and that is gotten at a 16-bit
+fan-out (64k-way), but for 100M keys, we would likely want at least 20-bit fan
+out.
+
+You can also see this from the original equation with a bit of rearranging::
+
+ epsilon = 1 - e^(-n^2 / 2^(h+1))
+ epsilon = 1 - e^(-(2^N)^2 / (2^(h+1))) = 1 - e^(-(2^(2N))(2^-(h+1)))
+ = 1 - e^(-(2^(2N - h - 1)))
+
+Such that you want ``2N - h`` to be a very negative integer, such that
+``2^-X`` is thus very close to zero, and ``1-e^0 = 0``. But you can see that
+if you want to double the number of source texts, you need to quadruple the
+number of bits.
+
+
+Scaling Sizes
+=============
+
+Scaling up
+----------
+
+We have said we want to be able to scale to a tree with 1M files and 1M
+commits. With a 255-way fan out for chk pages, you need 2 internal nodes,
+and a leaf node with 16 items. (You maintain 2 internal nodes up until 16.5M
+nodes, when you get another internal node, and your leaf nodes shrink down to
+1 again.) If we assume every commit averages 10 changes (large, but possible,
+especially with large merges), then you get 1 root + 10*(1 internal + 1 leaf
+node) per commit or 21 nodes per commit. At 1M revisions, that is 21M chk
+nodes. So to support the 1Mx1M project, we really need to consider having up
+to 100M chk nodes.
+
+Even if you went up to 16M tree nodes, that only bumps us up to 31M chk
+nodes. Though it also scales by number of changes, so if you had a huge churn,
+and had 100 changes per commit and a 16M node tree, you would have 301M chk
+nodes. Note that 8 bytes (64-bits) in the prefix still only gives us a 0.27%
+chance of collision (1 in 370). Or if you had 370 projects of that size, with
+all different content, *one* of them would have a collision in the index.
+
+We also should consider that you have the ``(parent_id,basename) => file_id``
+map that takes up its own set of chk pages, but testing seems to indicate that
+it is only about 1/10th that of the ``id_to_entry`` map. (rename,add,delete
+are much less common then content changes.)
+
+As a point of reference, one of the largest projects today OOo, has only 170k
+revisions, and something less than 100k files (and probably 4-5 changes per
+commit, but their history has very few merges, being a conversion from CVS).
+At 100k files, they are probably just starting to hit 2-internal nodes, so
+they would end up with 10 pages per commit (as a fair-but-high estimate), and
+at 170k revs, that would be 1.7M chk nodes.
+
+
+Scaling down
+------------
+
+While it is nice to scale to a 16M files tree with 1M files (100M total
+changes), it is also important to scale efficiently to more *real world*
+scenarios. Most projects will fall into the 255-64k file range, which is where
+you have one internal node and 255 leaf nodes (1-2 chk nodes per commit). And
+a modest number of changes (10 is generally a high figure). At 50k revisions,
+that would give you 50*2*10=500k chk nodes. (Note that all of python has 303k
+chk nodes, all of launchpad has 350k, mysql-5.1 in gc255 rather than gc255big had
+650k chk nodes, [depth=3].)
+
+So for these trees, scaling to 1M nodes is more than sufficient, and allows us
+to use a 6-byte prefix per record. At a minimum, group records could use a
+4-byte start and 3-byte length, but honestly, they are a tiny fraction of the
+overall index size, and it isn't really worth the implementation cost of being
+flexible here. We can keep a field in the header for the group record layout
+(8, 4) and for now just assert that this size is fixed.
+
+
+Other discussion
+================
+
+group encoding
+--------------
+
+In the above scheme we store the group locations as an 8-byte start, and
+4-byte length. We could theoretically just store a 4-byte length, and then you
+have to read all of the groups and add them up to determine the actual start
+position. The trade off is a direct jump-to-location versus storing 3x the
+data. Given when you have 64k groups you will need only .75MiB to store it,
+versus the 120MB for the actual entries, this seems to be no real overhead.
+Especially when you consider that 10M chk nodes should fit in only 250 groups,
+so total data is actually only 3KiB. Then again, if it was only 1KiB it is
+obvious that you would read the whole thing in one pass. But again, see the
+pathological "conversion creating 1 group per chk page" issue.
+
+Also, we might want to support more than 64k groups in a given index when we
+get to the point of storing file content in a CHK index. A lot of the analysis
+about the number of groups is based on the 100 byte compression of CHK nodes,
+which would not be true with file-content. We should compress well, I don't
+expect us to compress *that* well. Launchpad shows that the average size of a
+content record is about 500-600 bytes (after you filter out the ~140k that are
+NULL content records). At that size, you expect to get approx 7k records per
+group, down from 40k. Going further, though, you also want to split groups
+earlier, since you end up with better compression. so with 100,000 unique file
+texts, you end up with ~100 groups. With 1M revisions @ 10 changes each, you
+have 10M file texts, and would end up at 10,485 groups. That seems like more
+64k groups is still more than enough head room. You need to fit only 100
+entries per group, to get down to where you are getting into trouble (and have
+10M file texts.) Something to keep an eye on, but unlikely to be something
+that is strictly a problem.
+
+Still reasonable to have a record in the header indicating that index entries
+use a 2-byte group entry pointer, and allow it to scale to 3 (we may also find
+a win scaling it down to 1 in the common cases of <250 groups). Note that if
+you have the full 4MB groups, it takes 256 GB of compressed content to fill
+64k records. And our groups are currently scaled that we require at least
+1-2MB before they can be considered 'full'.
+
+
+variable length index entries
+-----------------------------
+
+The above had us store 8-bytes of sha hash, 2 bytes of group number, and
+2 bytes for record-in-group. However, since we have the variable-pointer
+mini-index, we could consider having those values be 'variable length'. So
+when you read the bytes between the previous-and-next record, you have a
+parser that can handle variable width. The main problem is that to encode
+start/stop of record takes some bytes, and at 12-bytes for a record, you don't
+have a lot of space to waste for a "end-of-entry" indicator. The easiest would
+be to store things in base-128 (high bit indicates the next byte also should
+be included).
+
+
+storing uncompressed offset + length
+------------------------------------
+
+To get the smallest index possible, we store only a 2-byte 'record indicator'
+inside the index, and then assume that it can be decoded once we've read the
+actual group. This is certainly possible, but it represents yet another layer
+of indirection before you can actually get content. If we went with
+variable-length index entries, we could probably get most of the benefit with
+a variable-width start-of-entry value. The length-of-content is already being
+stored as a base128 integer starting at the second byte of the uncompressed
+data (the first being the record type, fulltext/delta). It complicates some of
+our other processing, since we would then only know how much to decompress to
+get the start of the record.
+
+Another intriguing possibility would be to store the *end* of the record in
+the index, and then in the data stream store the length and type information
+at the *end* of the record, rather than at the beginning (or possibly at both
+ends). Storing it at the end is a bit unintuitive when you think about reading
+in the data as a stream, and figuring out information (you have to read to the
+end, then seek back) But a given GC block does store the
+length-of-uncompressed-content, which means we can trivially decompress, jump
+to the end, and then walk-backwards for everything else.
+
+Given that every byte in an index entry costs 10MiB in a 10M index, it is
+worth considering. At 4MiB for a block, base 128 takes 4 bytes to encode the
+last 50% of records (those beyond 2MiB), 3 bytes for everything from 16KiB =>
+2MiB. So the expected size is for all intents and purposes, 3.5 bytes. (Just
+due to an unfortunate effect of where the boundary is that you need more
+bytes.) If we capped the data at 2MB, the expected drops to just under 3
+bytes. Note that a flat 3bytes could decode up to 16MiB, which would be much
+better for our purpose, but wouldn't let us write groups that had a record
+after 16MiB, which doesn't work for the ISO case. Though it works *absolutely*
+fine for the CHK inventory cases (what we have today).
+
+
+null content
+------------
+At the moment, we have a lot of records in our per-file graph that refers to
+empty content. We get one for every symlink and directory, for every time that
+they change. This isn't specifically relevant for CHK pages, but for
+efficiency we could certainly consider setting "group = 0 entry = 0" to mean
+that this is actually a no-content entry. It means the group block itself
+doesn't have to hold a record for it, etc. Alternatively we could use
+"group=FFFF entry = FFFF" to mean the same thing.
+
+
+``VF.keys()``
+-------------
+At the moment, some apis expect that you can list the references by reading
+all of the index. We would like to get away from this anyway, as it doesn't
+scale particularly well. However, with this format, we no longer store the
+exact value for the content. The content is self describing, and we *would* be
+storing enough to uniquely decide which node to read. Though that is actually
+contained in just 4-bytes (2-byte group, 2-byte group entry).
+
+We use ``VF.keys()`` during 'pack' and 'autopack' to avoid asking for content
+we don't have, and to put a counter on the progress bar. For the latter, we
+can just use ``index.key_count()`` for the former, we could just properly
+handle ``AbsentContentFactory``.
+
+
+More than 64k groups
+--------------------
+Doing a streaming conversion all at once is still something to consider. As it
+would default to creating all chk pages in separate groups (300-400k easily).
+However, just making the number of group block entries variable, and allowing
+the pointer in each entry to be variable should suffice. At 3 bytes for the
+group pointer, we can refer to 16.7M groups. It does add complexity, but it is
+likely necessary to allow for arbitrary cases.
+
+..
+ vim: ft=rst tw=78 ai
diff --git a/doc/developers/incremental-push-pull.txt b/doc/developers/incremental-push-pull.txt
new file mode 100644
index 0000000..f8c009a
--- /dev/null
+++ b/doc/developers/incremental-push-pull.txt
@@ -0,0 +1,279 @@
+Incremental push/pull
+=====================
+
+This use case covers pulling in or pushing out some number of revisions which
+is typically a small fraction of the number already present in the target
+repository. Pushing and pulling are defined as branch level operations for ease
+of interaction with VCS systems that have no repository abstraction (such as
+bzr-svn or GNU Arch) but within bzrlib's core they are currently the
+responsibility of the Repository object.
+
+Functional Requirements
+-----------------------
+
+A push or pull operation must:
+ * Copy all the data to reconstruct the selected revisions in the target
+ branch. This is the goal of push and pull after all.
+ * Reject corrupt data. As bzr has no innate mechanism for discarding corrupted
+ data, corrupted data should not be incorporated accidentally.
+
+Factors which should add work for push/pull
+-------------------------------------------
+
+ * Baseline overhead: The time to connect to both branches.
+ * Actual new data in the revisions being pulled (drives the amount of data to
+ move around, includes the commit messages etc)
+ * Number of revisions in the two repositories (scaling affects the
+ determination of what revisions to move around).
+
+Push/pull overview
+------------------
+
+1. New data is identified in the source repository.
+2. That data is read from the source repository.
+3. The same data is verified and written to the target repository in such a
+ manner that it's not visible to readers until it's ready for use.
+
+New data identification
+~~~~~~~~~~~~~~~~~~~~~~~
+
+We have a single top level data object: revisions. Everything else is
+subordinate to revisions, so determining the revisions to propagate should be
+all thats needed. This depends on revisions with partial data - such as those
+with no signature - being flagged in some efficient manner.
+
+We could do this in two manners: determine revisions to sync and signatures to sync in two passes, or change the 'value' of a revision implicitly when the signature is different. E.g. by using merkle hash trees with the signature data a separate component the signatures will naturally be identified to sync.
+
+We want to only exchange data proportional to the number of new revisions and
+signatures in the system though. One way to achieve this for revisions is to
+walk the graph out from the desired tips until the surface area intersection is
+found. For signatures a set difference seems to be needed as there is no DAG of signatures: the presence of one has no implications on the presence of another, so a full pass over the set of signatures would be required to confirm no new signatures are needed (let alone replaced signatures).
+
+IFF we can determine 'new revisions' and 'new signatures' without full graph access then we can scale acceptable for push and pull.
+
+Ghosts are revisions which are not present in a particular repository. Filling ghosts refers to removing ghosts in the target repository when the ghost is present in the source repository. Filling ghosts can be either an explicit or implicit action. The common case is no ghosts.
+
+Set synchronisation approaches
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A set synchronisation approach is one which synchronises two sets without
+regard for innate structure. This can be very efficient but requires adding a
+new node to be processed with every commit. Caching of the results of the
+various set based syncs I've seen is possible but because the data structures
+look different depending on the tip revision being synced up to the cache needs
+to be very complex. I recommend not using such an approach for the common case
+pull because of the failure to scale. We can use such an approach for
+synchronisation of new signatures and ghosts, which should be an explicit
+option in both cases.
+
+DAG synchronisation approaches
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A DAG based approach to synchronistion is one that uses the DAG structure to
+determine the difference in present nodes. It can as a result operate from the
+tip of the DAG backwards. A dag based approach should allow incremental access
+to data and not require a full-graph scan for incremental operations.
+
+File level scaling
+^^^^^^^^^^^^^^^^^^
+
+We should read roughly as much of the revision level graph as is needed from
+each repository to determine the node difference. If requested we should
+perform a detailed scan to pick up ghost revisions and revisions which have had
+signatures added. This should not be the default as it requires full history
+access in both cases.
+
+Expected file IO and access pattern:
+
+ * Common case: repo with many branches of one project, to the same.
+
+ 1. Source and Target branch tips read.
+ 2. Find the tip of each branch in their repo (will require reading some of
+ the revision graph but is typically near the end of the graph).
+ 3. Read and parse increasing amounts of the revision graph until one is
+ found to be a subset of the other, or a complete list of revisions to be
+ transmitted is created.
+
+ * Uncommon cases:
+
+ 1. Repositories with many projects or branches which are very old may
+ require reading a lot of unrelated graph data.
+
+ 1. Initial push/pull scenarios should not require reading an entire graph.
+
+
+API scaling
+^^^^^^^^^^^
+
+ 1. Get branch tips.
+ 2. Determine one sided graph difference. To avoid obtaining a full graph over
+ the wire this needs to be done without reference to the full graph, and
+ with some logarthmic scaling algorithm. There are several already available
+ for this.
+
+With ghost and new-signature detection:
+
+ * File IO access pattern will read the entire graph on the 'target' side - if
+ no ghosts are present then stop, otherwise seek the new revisions on the
+ source side with the regular algorithm and also explicitly search for the
+ ghost points from the target; plus a set difference search is needed on
+ signatures.
+
+ * Semantic level can probably be tuned, but as it's also complex I suggest
+ deferring analysis for optimal behaviour of this use case.
+
+
+Data reading
+~~~~~~~~~~~~
+
+When transferring information about a revision the graph of data for the
+revision is walked: revision -> inventory, revision -> matching signature,
+inventory -> file ids:revision pairs.
+
+File level scaling
+^^^^^^^^^^^^^^^^^^
+
+As we're reading already committed data, as long as nothing is mutating data on
+disk reading should be race free. We will:
+
+ - read each revision object
+ - read the matching inventory delta
+ - attempt to read a signature object
+ - parse the inventory delta
+ - read the fileid:revisionid compressed chunk for each line in the inventory
+ delta
+
+Theres no point validating that the data read is valid, as transmission through to the client writing the data might invalidate it; we need to validate before we write.
+
+API scaling
+^^^^^^^^^^^
+
+Given that we have established the revisions needed, a single API call should
+suffice to obtain all data; the API should present the data in such an order
+that it can be validated as it arrives and thus not require large scale
+buffering on disk. Specifically each item of data should be validatable (e.g.
+for some file data we want the fileid:revisionid:validationhash + content).
+
+
+Data Verification and writing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New data written to a repository should be completed intact when it is made
+visible. This suggests that either all the data for a revision must be made
+atomically visible (e.g. by renaming a single file) or the leaf nodes of the
+reference graph must become visible first.
+
+Data is referred to via the following graph:
+revision -> revision
+revision -> signature
+revision -> inventory
+inventory -> fileid:revisionid
+fileid:revisionid -> fileid:revisionid
+
+Data is verifiable via a different ordering:
+signature -> revision -> inventory -> fileid:revisionid texts.
+
+We dont gpg verify each revision today; this analysis only speaks to hash
+verification of contents.
+
+To validate a revision we need to validate the data it refers to. But to
+validate the contents of a revision we need the new texts in the inventory for
+the revision - to check a fileid:revisionid we need to know the expected sha1
+of the full text and thus also need to read the delta chain to construct the
+text as we accept it to determine if it's valid. Providing separate validators
+for the chosen representation would address this.
+e.g: For an inventory entry FILEID:REVISIONID we store the validator of the
+full text :SHA1:. If we also stored the validator of the chosen disk
+representation (:DELTASHA1:) we could validate the transmitted representation
+without expanding the delta in the common case. If that failed we could expand
+the delta chain and try against the full text validator, and finally fail. As
+different delta generators might generate different deltas, :DELTASHA1: should
+not become part of the revision validator, only the inventory disk encoding. In
+a related manner a transmission format that allowed cheap validation of content
+without applying locally stored deltas would be advantageous because no local
+reads would be incurred to validate new content. For instance, always sending a
+full text for any file, possibly with a delta-chain when transmitting multiple
+revisionids of the file, would allow this. (git pack-files have this property).
+
+Overview summary
+^^^^^^^^^^^^^^^^
+
+A single-file local format would allow safe atomic addition of data while
+allowing optimisal transmission order of data. Failing this the validation of
+data should be tuned to not require reading local texts during data addition
+even in the presence of delta chains. We should have transmission-validators
+separate from content validators that allow validation of the delta-transmitted
+form of objects.
+
+File level scaling
+^^^^^^^^^^^^^^^^^^
+
+* Every new file text requires transmission and local serialisation.
+* Every commit requires transmission and storage of a revision, signature and inventory.
+
+Thus 4000 commits to a 50000 path tree of 10 files on averages requires (with
+knits) between 26 writes (2*(3+10)) and 80006 (2*(4000*10 + 3)) writes. In all
+cases there are 4000 * 13 distinct objects to record.
+
+Grouping data by fileid, content and metadata, gives the figures above.
+Data grouping:
+
+* File per full identifier (fileid:revisionid:meta|content): 104000
+* Delta-chain per object: object id count * constant overhead per object id
+ (26 -> 80006)
+* Collation/pack file: 1
+
+Performance for these depends heavily on implementation:
+ - Using full ids we could name by validator or by id, giving best performance
+ that depends on either receiving data in validator order or in id order.
+ - using delta-chain per object we get least seek overhead and syscall overhead
+ if we recieve in topological order within the object id, and object ids in
+ lexical order.
+ - Using a collation/pack file we can stream it into place and validate as we go,
+ giving near ideal performance.
+
+API scaling
+^^^^^^^^^^^
+
+The api for writing new data recieved over the network will need to be geared
+to the transmission and local storage method. What we need is for the
+transmission method to reasonably closely match the desired write ordering
+locally. This suggests that once we decide on the best local storage means we
+should design the api.
+
+
+take N commits from A to B, if B is local then merge changes into the tree.
+copy ebough data to recreate snapshots
+avoid ending up wth corrupt/bad data
+
+Notes from London
+-----------------
+
+ #. setup
+
+ look at graph of revisions for ~N comits to deretmine eligibility for
+ if preserve mainline is on, check LH only
+
+ identify objects to send that are not on the client repo
+ - revision - may be proportional to the graph
+ - inventory - proportional to work
+ - texts - proportional to work
+ - signatures - ???
+
+ #. data transmission
+
+ * send data proportional to the new information
+ * validate the data:
+
+ #. validate the sha1 of the full text of each transmitted text.
+ #. validate the sha1:name mapping in each newly referenced inventory item.
+ #. validate the sha1 of the XML of each inventory against the revision.
+ **this is proportional to tree size and must be fixed**
+
+ #. write the data to the local repo.
+ The API should output the file texts needed by the merge as by product of the transmission
+
+ #. tree application
+
+Combine the output from the transmission step with additional 'new work data' for anything already in the local repository that is new in this tree.
+should write new files and stat existing files proportional to the count of the new work and the size of the full texts.
diff --git a/doc/developers/index-plain.txt b/doc/developers/index-plain.txt
new file mode 100644
index 0000000..f71e2b9
--- /dev/null
+++ b/doc/developers/index-plain.txt
@@ -0,0 +1,158 @@
+=================================
+Bazaar Developer Document Catalog
+=================================
+
+
+Overall developer documentation
+===============================
+
+* `Developer Guide <HACKING.html>`_
+
+* `Architectural Overview <overview.html>`_ |--| describes some of the
+ most important classes and concepts.
+
+* `bzrlib API reference <http://people.canonical.com/~mwh/bzrlibapi/>`_
+ (external link)
+ |--| automatically generated API reference information
+
+* `Integrating with Bazaar <http://wiki.bazaar.canonical.com/Integrating_with_Bazaar>`_
+ (wiki) |--| a guide for writing Python programs that work with Bazaar.
+
+* `Revision Properties <revision-properties.html>`_ |--| An application
+ can set arbitrary per-revision key/value pairs to store app-specific
+ data.
+
+* `Testing <testing.html>`_ |--| Guide to writing tests for Bazaar.
+
+* `Code Review <code-review.html>`_.
+
+* `Bazaar Code Style Guide <code-style.html>`_.
+
+* `Writing plugins <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_
+ |--| specific advice on writing Bazaar plugins. (web link)
+
+* `Documenting changes <documenting-changes.html>`_.
+
+Process
+=======
+
+* `The Bazaar Development Cycle <cycle.html>`_ |--| The monthly
+ development cycle and how to run it.
+
+* `Releasing Bazaar <releasing.html>`_ |--|
+ Checklist to make a release of Bazaar.
+
+* `Managing the Bazaar PPA <ppa.html>`_ |--| Packaging Bazaar for Ubuntu.
+
+* `Giving back <http://wiki.bazaar.canonical.com/BzrGivingBack>`_ (wiki) |--| How to get
+ your changes to Bazaar integrated into a release.
+
+* `Profiling notes <profiling.html>`_ |--| Instructions on how to profile
+ bzr code and visualize the results.
+
+* `EC2 resources <ec2.html>`_ |--| A team resource for
+ Windows packaging and testing, and Ubuntu testing.
+
+* `Tracking Bugs in Bazaar <bug-handling.html>`_ |--| How we use the bug
+ tracker.
+
+Architecture overviews
+======================
+
+* `Transports <transports.html>`_ |--| Transport virtual filesystem
+ abstraction.
+
+Plans
+=====
+
+* `Performance roadmap <performance-roadmap.html>`_ |--| The roadmap
+ for fixing performance in bzr over the next few releases.
+
+* `Co-located branches <colocated-branches.html>`_ |--| Planned(?) support
+ for storing multiple branches in one file-system directory.
+
+* `Bazaar Windows Shell Extension Options <tortoise-strategy.html>`_ |--|
+ Implmentation strategy for Bazaar Windows Shell Extensions, aka
+ TortoiseBzr.
+
+* `CHK Optimized index <improved_chk_index.html>`_
+
+Specifications
+==============
+
+* `API versioning <api-versioning.html>`_ |--| bzrlib API versioning.
+
+* `Apport error reporting <apport.html>`_ |--| Capture data to report
+ bugs.
+
+* `Authentication ring <authentication-ring.html>`_ |--| Configuring
+ authentication.
+
+* `Bundles <bundles.html>`_ |--| All about bzr bundles.
+
+* `Container format <container-format.html>`_ |--| Notes on a container format
+ for streaming and storing Bazaar data.
+
+* `Groupcompress <groupcompress-design.html>`_ |--| Notes on the compression
+ technology used in CHK repositories.
+
+* `Indices <indices.html>`_ |--| The index facilities available within bzrlib.
+
+* `Inventories <inventory.html>`_ |--| Tree shape abstraction.
+
+* `LCA merge <lca-merge.html>`_ |--| A nice new merge algorithm.
+
+* `Network protocol <network-protocol.html>`_ |--| Custom network protocol.
+
+* `Plugin APIs <plugin-api.html>`_ |--| APIs plugins should use.
+
+* `Repositories <repository.html>`_ |--| What repositories do and are used for.
+
+* `Repository stream <repository-stream.html>`_ |--| Notes on streaming data
+ for repositories (a layer above the container format).
+
+* `Integration Guide <integration.html>`_ |--| A guide to integrate bzrlib into
+ any python application.
+
+* `Bazaar and case-insensitive file systems <case-insensitive-file-systems.html>`_
+ |--| How Bazaar operates on case-insensitive file systems such as commonly
+ found on Windows, USB sticks, etc.
+
+* `Development repository formats <development-repo.html>`_ |--| How to
+ work with repository formats that are still under development.
+ Contains instructions for those implementing new formats, of course,
+ but also for (bleeding-edge) end users of those formats.
+
+Data formats
+============
+
+* `Knit pack repositories <packrepo.html>`_ |--| KnitPack repositories
+ (new in Bazaar 0.92).
+
+Implementation notes
+====================
+
+* `BTree Index Prefetch <btree_index_prefetch.html>`_ |--| How bzr decides
+ to pre-read extra nodes in the btree index.
+
+* `Computing last_modified values <last-modified.html>`_ for inventory
+ entries
+
+* `Content filtering <content-filtering.html>`_
+
+* `LCA Tree Merging <lca_tree_merging.html>`_ |--| Merging tree-shape when
+ there is not a single unique ancestor (criss-cross merge).
+
+Miscellaneous
+=============
+
+* `dirstate <dirstate.html>`_ |--| An observation re. the dirstate file
+
+* `"bzr update" performance analysis <update.html>`_ |--| "bzr update"
+ performance analysis
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/index.txt b/doc/developers/index.txt
new file mode 100644
index 0000000..d674dbd
--- /dev/null
+++ b/doc/developers/index.txt
@@ -0,0 +1,94 @@
+=================================
+Bazaar Developer Document Catalog
+=================================
+
+
+Introduction
+============
+
+.. toctree::
+ :maxdepth: 1
+
+ contribution-quickstart
+
+
+Working on Bazaar
+=================
+
+.. toctree::
+ :maxdepth: 1
+
+ cycle
+ profiling
+ bug-handling
+ HACKING
+ testing
+ code-review
+ code-style
+ documenting-changes
+
+* `Contributing to Bazaar Documentation <http://wiki.bazaar.canonical.com/ContributingToTheDocs>`_ (wiki)
+
+
+Architecture overviews
+======================
+
+.. toctree::
+ :maxdepth: 1
+
+ configuration
+ fetch
+ transports
+ ui
+
+Releasing and Packaging
+=======================
+
+.. toctree::
+ :maxdepth: 1
+
+ releasing
+ ppa
+ ec2
+
+
+Developing using bzrlib
+=======================
+
+.. toctree::
+ :maxdepth: 1
+
+ overview
+ integration
+
+* `Writing plugins for Bazaar <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_ (web link)
+
+* `bzrlib API reference <http://people.canonical.com/~mwh/bzrlibapi/>`_
+ (web link)
+
+
+Other documents
+===============
+
+.. toctree::
+ :maxdepth: 1
+
+ principles
+ plans
+ specifications
+ implementation-notes
+ miscellaneous-notes
+
+
+Licence
+============
+
+Copyright 2005-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/indices.txt b/doc/developers/indices.txt
new file mode 100644
index 0000000..cf6797b
--- /dev/null
+++ b/doc/developers/indices.txt
@@ -0,0 +1,111 @@
+=======
+Indices
+=======
+
+Status
+======
+
+:Date: 2007-07-14
+
+This document describes the indexing facilities within bzrlib.
+
+
+.. contents::
+
+
+Motivation
+==========
+
+To provide a clean concept of index that can be reused by different
+components within the codebase rather than being rewritten every time
+by different components.
+
+
+Terminology
+===========
+
+An **index** is a dictionary mapping opaque keys to opaque values.
+Different index types may allow some of the value data to be interpreted
+by the index. For example the ``GraphIndex`` index stores a graph between
+keys as part of the index.
+
+
+Overview
+========
+
+bzr is moving to a write-once model for repository storage in order to
+achieve lock-free repositories eventually. In order to support this, we are
+making our new index classes **immutable**. That is, one creates a new
+index in a single operation, and after that it is read only. To combine
+two indices a ``Combined*`` index may be used, or an **index merge** may
+be performed by reading the entire value of two (or more) indices and
+writing them into a new index.
+
+General Index API
+=================
+
+We may end up with multiple different Index types (e.g. GraphIndex,
+Index, WhackyIndex). Even though these may require different method
+signatures to operate would strive to keep the signatures and return
+values as similar as possible. e.g.::
+
+ GraphIndexBuilder - add_node(key, value, references)
+ IndexBuilder - add_node(key, value)
+ WhackyIndexBuilder - add_node(key, value, whackiness)
+
+as opposed to something quite different like::
+
+ node = IncrementalBuilder.get_node()
+ node.key = 'foo'
+ node.value = 'bar'
+
+Services
+--------
+
+An initial implementation of indexing can probably get away with a small
+number of primitives. Assuming we have write once index files:
+
+Build index
+~~~~~~~~~~~
+
+This should be done by creating an ``IndexBuilder`` and then calling
+``insert(key, value)`` many times. (Indices that support sorting,
+topological sorting etc, will want specialised insert methods).
+
+When the keys have all been added, a ``finish`` method should be called,
+which will return a file stream to read the index data from.
+
+Retrieve entries from the index
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This should allow random access to the index using readv, so we probably
+want to open the index on a ``Transport``, then use ``iter_entries(keys)``,
+which can return an iterator that yields ``(key, value)`` pairs in
+whatever order makes sense for the index.
+
+Merging of indices
+~~~~~~~~~~~~~~~~~~
+
+Merging of N indices requires a concordance of the keys of the index. So
+we should offer a ``iter_all_entries`` call that has the same return type
+as the ``iter_entries`` call.
+
+Index implementations
+=====================
+
+GraphIndex
+----------
+
+``GraphIndex`` supports graph based lookups. While currently unoptimised
+for reading, the index is quite space efficient at storing the revision
+graph index for bzr. The ``GraphIndexBuilder`` may be used to create one
+of these indices by calling ``add_node`` until all nodes are added, then
+``finish`` to obtain a file stream containing the index data. Multiple
+indices may be queried using the ``CombinedGraphIndex`` class.
+
+
+
+
+..
+ vim: ft=rst tw=74 ai
+
diff --git a/doc/developers/initial-push-pull.txt b/doc/developers/initial-push-pull.txt
new file mode 100644
index 0000000..046d805
--- /dev/null
+++ b/doc/developers/initial-push-pull.txt
@@ -0,0 +1,69 @@
+Initial push / pull
+===================
+
+Optimal case
+------------
+(a motivating example of ultimate performance)
+Assume there is a file with exactly the right data in compressed form. This
+may be a tarred branch, a bundle, or a blob format. Performance in this case
+scales with the size of the file.
+
+Disk case
+---------
+Assume current repo format. Attempt to achieve parity with ``cp -r``. Read
+each file only 1 time.
+
+- read knit graph for revisions
+- write filtered copy of revision knit O(d+a)
+- write filtered copy of knit index O(d)
+- Open knit index for inventory
+- Write a filtered copy of inventory knit and simultaneously not all referenced
+ file-ids O(b+d)
+- Write filtered copy of inventory knit index O(d)
+- For each referenced file-id:
+
+ - Open knit index for each file knit O(e)
+ - If acceptable threshold of irrelevant data hard-link O(f)
+ - Otherwise write filtered copy of text knit and simultaneously write
+ the fulltext to tree transform O(h)
+
+- Write format markers O(1)
+
+:a: size of aggregate revision metadata
+:b: size of inventory changes for all revisions
+:c: size of text changes for all files and all revisions (e * g)
+:d: number of relevant revisions
+:e: number of relevant versioned files
+:f: size of the particular versioned file knit index
+:g: size of the filtered versioned file knit
+:h: size of the versioned file fulltext
+:i: size of the largest file fulltext
+
+Smart Network Case
+------------------
+
+Phase 1
+~~~~~~~
+Push: ask if there is a repository, and if not, what formats are okay
+Pull: Nothing
+
+Phase 2
+~~~~~~~
+Push: send initial push command, streaming data in acceptable format, following
+disk case strategy
+Pull: receive initial pull command, specifying format
+
+Pull client complexity: O(a), memory cost O(1)
+Push client complexity: procesing and memory cost same as disk case
+
+Dumb Network Case
+-----------------
+Pull: same as disk case, but request all file knit indices at once and request
+al file knits at once.
+Push: same as disk case, but write all files at once.
+
+Wants
+-----
+- Read partial graph
+- Read multiple segments of multiple files on HTTP and SFTP
+- Write multiple files over SFTP
diff --git a/doc/developers/integration.txt b/doc/developers/integration.txt
new file mode 100644
index 0000000..88374c2
--- /dev/null
+++ b/doc/developers/integration.txt
@@ -0,0 +1,362 @@
+=======================
+Integrating with Bazaar
+=======================
+
+This document provides some general observations on integrating with
+Bazaar and some recipes for typical tasks. It is intended to be useful to
+someone developing either a plugin or some other piece of software that
+integrates with bzr. If you want to know about a topic that's not covered
+here, just ask us.
+
+
+
+
+Starting with bzrlib
+====================
+
+Within bzr
+----------
+
+When using bzrlib within the ``bzr`` program (for instance as a bzr
+plugin), bzrlib's global state is already available for use.
+
+From outside bzr
+----------------
+
+To use bzrlib outside of ``bzr`` some global state needs to be setup.
+bzrlib needs ways to handle user input, passwords, a place to emit
+progress bars, logging setup appropriately for your program. The easiest
+way to set all this up in the same fashion ``bzr`` does is to call
+``bzrlib.initialize``.
+
+This returns a context manager within which bzrlib functions will work
+correctly. See the pydoc for ``bzrlib.initialize`` for more information.
+(You can get away without entering the context manager, because the setup
+work happens directly from ``initialize``.)
+
+In Python 2.4 the ``with`` keyword is not supported and
+so you need to use the context manager manually::
+
+ # This sets up your ~/.bzr.log, ui factory and so on and so forth. It is
+ # not safe to use as a doctest.
+ library_state = bzrlib.initialize()
+ library_state.__enter__()
+ try:
+ pass
+ # do stuff here
+ finally:
+ library_state.__exit__(None, None, None)
+
+
+Running bzr commands
+====================
+
+To run command-line commands in-process::
+
+ from bzrlib.commands import get_command
+
+ cmd = get_command('version')
+ cmd.run([])
+
+This will send output through the current UIFactory; you can redirect this
+elsewhere through the parameters to `bzrlib.initialize`.
+
+
+Manipulating the Working Tree
+=============================
+Most objects in Bazaar are in files, named after the class they contain.
+To manipulate the Working Tree we need a valid WorkingTree object, which
+is loaded from the workingtree.py file, eg::
+
+ from bzrlib import workingtree
+ wt = workingtree.WorkingTree.open('/home/jebw/bzrtest')
+
+
+This gives us a WorkingTree object, which has various methods spread over
+itself, and its parent classes MutableTree and Tree - it's worth having a
+look through these three files (workingtree.py, mutabletree.py and tree.py)
+to see which methods are available.
+
+Compare trees
+-------------
+
+There are two methods for comparing trees: ``changes_from`` and
+``iter_changes``. ``iter_changes`` is more regular and precise, but it is
+somewhat harder to work with. See the API documentation for more details.
+
+``changes_from`` creates a Delta object showing changes::
+
+ from bzrlib import delta
+ changes = wt.changes_from(wt.basis_tree())
+
+This gives us a Delta object, which has several lists of files for each type of
+change, eg changes.added is a list of added files, changes.removed is list
+of removed files, changes.modified is a list of modified files. The contents
+of the lists aren't just filenames, but include other information as well.
+To grab just the filename we want the first value, eg::
+
+ print("list of newly added files")
+ for filename in changes.added:
+ print("%s has been added" % filename[0])
+
+
+The exception to this is changes.renamed, where the list returned for each
+renamed files contains both the old and new names -- one or both may interest
+you, depending on what you're doing.
+
+For example::
+
+ print("list of renamed files")
+ for filename in changes.renamed:
+ print("%s has been renamed to %s" % (filename[0], filename[1]))
+
+
+Adding Files
+------------
+
+If you want to add files the same way ``bzr add`` does, you can use
+MutableTree.smart_add. By default, this is recursive. Paths can either be
+absolute or relative to the workingtree::
+
+ wt.smart_add(['dir1/filea.txt', 'fileb.txt',
+ '/home/jebw/bzrtesttree/filec.txt'])
+
+
+For more precise control over which files to add, use MutableTree.add::
+
+ wt.add(['dir1/filea.txt', 'fileb.txt', '/home/jebw/bzrtesttree/filec.txt'])
+
+
+Removing Files
+--------------
+
+You can remove multiple files at once. The file paths need to be relative
+to the workingtree::
+
+ wt.remove(['filea.txt', 'fileb.txt', 'dir1'])
+
+
+By default, the files are not deleted, just removed from the inventory.
+To delete them from the filesystem as well::
+
+ wt.remove(['filea.txt', 'fileb.txt', 'dir1'], keep_files=False)
+
+
+Renaming a File
+---------------
+
+You can rename one file to a different name using WorkingTree.rename_one.
+You just provide the old and new names, eg::
+
+ wt.rename_one('oldfile.txt','newfile.txt')
+
+
+Moving Files
+------------
+
+You can move multiple files from one directory into another using
+WorkingTree.move::
+
+ wt.move(['olddir/file.txt'], 'newdir')
+
+
+More complicated renames/moves can be done with transform.TreeTransform,
+which is outside the scope of this document.
+
+
+Committing Changes
+------------------
+
+To commit _all_ the changes to our working tree we can just call the
+WorkingTree's commit method, giving it a commit message, eg::
+
+ wt.commit('this is my commit message')
+
+
+To commit only certain files, we need to provide a list of filenames which we
+want committing, eg::
+
+ wt.commit(message='this is my commit message', specific_files=['fileA.txt',
+ 'dir2/fileB.txt', 'fileD.txt'])
+
+
+Generating a Log for a File
+===========================
+
+Generating a log is, in itself, simple. Grab a branch (see below) and pass
+it to show_log together with a log formatter, eg::
+
+ from bzrlib import log
+ from bzrlib import branch
+
+ b = branch.Branch.open('/path/to/bazaar/branch')
+ lf = log.LongLogFormatter(to_file=sys.stdout)
+ log.show_log(b, lf)
+
+
+Three log formatters are included with bzrlib: LongLogFormatter,
+ShortLogFormatter and LineLogFormatter. These provide long, short and
+single-line log output formats. It's also possible to write your own in
+very little code.
+
+Annotating a File
+=================
+
+To annotate a file, we want to walk every line of a file, retrieving the
+revision which last modified/created that line and then retrieving the
+information for that revision.
+
+First we get an annotation iterator for the file we are interested in::
+
+ tree, relpath = workingtree.WorkingTree.open_containing('/path/to/file.txt')
+ fileid = tree.path2id(relpath)
+ annotation = list(tree.annotate_iter(fileid))
+
+
+To avoid repeatedly retrieving the same revisions we grab all revisions
+associated with the file at once and build up a map of id to revision
+information. We also build an map of revision numbers, again indexed
+by the revision id::
+
+ revision_ids = set(revision_id for revision_id, text in annotation)
+ revisions = tree.branch.repository.get_revisions(revision_ids)
+ revision_map = dict(izip(revision_ids, revisions))
+ revno_map = tree.branch.get_revision_id_to_revno_map()
+
+
+Finally, we use our annotation iterator to walk the lines of the file,
+displaying the information from our revision maps as we go::
+
+ for revision_id, text in annotation :
+ rev = revision_map[revision_id]
+ revno = revno_map[revision_id]
+ revno_string = '.'.join(str(i) for i in revno)
+ print "%s, %s: %s" % (revno_string, rev.committer, text)
+
+
+Working with branches
+=====================
+
+To work with a branch you need a branch object, created from your branch::
+
+ from bzrlib import branch
+
+ b = branch.Branch.open('/home/jebw/bzrtest')
+
+
+Branching from an existing branch
+---------------------------------
+
+To branch you create a branch object representing the branch you are
+branching from, and supply a path/url to the new branch location.
+The following code clones the bzr.dev branch (the latest copy of the Bazaar
+source code) - be warned it has to download 60meg so takes a while to run
+with no feedback::
+
+ from bzrlib import branch
+
+ b = branch.Branch.open('http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev')
+ nb = b.bzrdir.sprout('/tmp/newBzrBranch').open_branch()
+
+
+This provides no feedback, since Bazaar automatically uses the 'silent' UI.
+
+
+Pushing and pulling branches
+----------------------------
+
+To push a branch you need to open the source and destination branches, then
+just call push with the other branch as a parameter::
+
+ from bzrlib import branch
+
+ b1 = branch.Branch.open('file:///home/user/mybranch')
+ b2 = branch.Branch.open('http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev')
+ b1.push(b2)
+
+
+Pulling is much the same::
+
+ b1.pull(b2)
+
+
+If you have a working tree, as well as a branch, you should use
+WorkingTree.pull, not Branch.pull.
+
+This won't handle conflicts automatically though, so any conflicts will be
+left in the working tree for the user to resolve.
+
+
+Checkout from an existing branch
+================================
+
+This performs a Lightweight checkout from an existing Branch::
+
+ from bzrlib import bzrdir
+
+ accelerator_tree, source = bzrdir.BzrDir.open_tree_or_branch('http:URL')
+ source.create_checkout('/tmp/newBzrCheckout', None, True, accelerator_tree)
+
+
+To make a heavyweight checkout, change the last line to::
+
+ source.create_checkout('/tmp/newBzrCheckout', None, False, accelerator_tree
+
+
+History Operations
+==================
+
+Finding the last revision number or id
+--------------------------------------
+
+To get the last revision number and id of a branch use::
+
+ revision_number, revision_id = branch.last_revision_info()
+
+
+If all you care about is the revision_id there is also the
+method::
+
+ revision_id = branch.last_revision()
+
+
+Getting the list of revision ids that make up a branch
+------------------------------------------------------
+
+IMPORTANT: This should be avoided wherever possible, as it scales with the
+length of history::
+
+ revisions = branch.revision_history()
+
+now revisions[0] is the revision id of the first commit, and revs[-1] is the
+revision id of the most recent. Note that if all you want is the last
+revision then you should use branch.last_revision() as described above, as
+it is vastly more efficient.
+
+
+Getting a Revision object from a revision id
+--------------------------------------------
+
+The Revision object has attributes like "message" to get the information
+about the revision::
+
+ repo = branch.repository
+ revision = repo.get_revision(rev_id)
+
+
+Accessing the files from a revision
+-----------------------------------
+
+To get the file contents and tree shape for a specific revision you need
+a RevisionTree. These are supplied by the repository for a specific
+revision id::
+
+ revtree = repo.revision_tree(rev_id)
+
+RevisionTrees, like all trees, can be compared as described in "Comparing
+Trees" above.
+
+The most common way to list files in a tree is ``Tree.iter_entries()``.
+The simplest way to get file content is ``Tree.get_file()``. The best way
+to retrieve file content for large numbers of files `Tree.iter_files_bytes()``
+
diff --git a/doc/developers/inventory.txt b/doc/developers/inventory.txt
new file mode 100644
index 0000000..2b7a727
--- /dev/null
+++ b/doc/developers/inventory.txt
@@ -0,0 +1,613 @@
+===========
+Inventories
+===========
+
+.. contents::
+
+Overview
+========
+
+Inventories provide an abstraction for talking about the shape of a tree.
+Generally only tree object implementors should be concerned about entire
+inventory objects and their implementation. Other common exceptions are
+full-tree operations such as 'checkout', 'export' and 'import'.
+
+In memory inventories
+=====================
+
+In memory inventories are often used in diff and status operations between
+trees. We are working to reduce the number of times this occurs with 'full
+tree' inventory objects, and instead use more custom tailored data structures
+that allow operations on only a small amount of data regardless of the size of
+the tree.
+
+
+Serialization
+=============
+
+There are several variants of serialised tree shape in use by bzr. To date
+these have been mostly XML-based, though plugins have offered non-XML versions.
+
+dirstate
+--------
+
+The dirstate file in a working tree includes many different tree shapes - one
+for the working tree and one for each parent tree, interleaved to allow
+efficient diff and status operations.
+
+XML
+---
+
+All the XML serialized forms write to and read from a single byte string, whose
+hash is then the inventory validator for the commit object.
+
+
+Serialization scaling and future designs
+========================================
+
+Overall efficiency and scaling is constrained by the bottom level structure
+that an inventory is stored as. We have a number of goals we want to achieve:
+
+ 1. Allow commit to write less than the full tree's data in to the repository
+ in the general case.
+ 2. Allow the data that is written to be calculated without examining every
+ versioned path in the tree.
+ 3. Generate the exact same representation for a given inventory regardless of
+ the amount of history available.
+ 4. Allow in memory deltas to be generated directly from the serialised form
+ without upcasting to a full in-memory representation or examining every
+ path in the tree. Ideally the work performed will be proportional to the
+ amount of changes between the trees being compared.
+ 5. Allow fetch to determine the file texts that need to be pulled to ensure
+ that the entire tree can be reconstructed without having to probe every
+ path in the tree.
+ 6. Allow bzr to map paths to file ids without reading the entire serialised
+ form. This is something that is used by commands such as merge PATH and
+ diff -r X PATH.
+ 7. Let bzr map file ids to paths without reading the entire serialised form.
+ This is used by commands that are presenting output to the user such as
+ loggerhead, bzr-search, log FILENAME.
+ 8. We want a strong validator for inventories which is cheap to generate.
+ Specifically we should be able to create the generator for a new commit
+ without processing all the data of the basis commit.
+ 9. Testaments generation is currently size(tree), we would like to create a
+ new testament standard which requires less work so that signed commits
+ are not significantly slower than regular commits.
+
+
+We have current performance and memory bugs in log -v, merge, commit, diff -r,
+loggerhead and status -r which can be addressed by an inventory system
+meeting these goals.
+
+Current situation
+-----------------
+
+The XML-based implementation we use today layers the inventory as a bytestring
+which is stored under a single key; the bytestring is then compressed as a
+delta against the bytestring of its left hand parent by the knit code.
+
+Gap analysis:
+
+ 1. Succeeds
+ 2. Fails - generating a new XML representation needs full tree data.
+ 3. Succeeds - the inventory layer accesses the bytestring, which is
+ deterministic
+ 4. Fails - we have to reconstruct both inventories as trees and then delta
+ the resulting in memory objects.
+ 5. Partial success - the revision field in the inventory can be scanned for
+ in both text-delta and full-bytestring form; other revision values than
+ those revisions which are being pulled are by definition absent.
+ 6. Partially succeeds - with appropriate logic a path<->id map can be generated
+ just-in-time, but it is complex and still requires reconstructing the
+ entire byte-string.
+ 7. As for 6.
+ 8. Fails - we have to hash the entire tree in serialised form to generate
+ validators.
+ 9. Fails.
+
+Long term work
+--------------
+
+Some things are likely harder to fix incrementally than others. In particular,
+goal 3 (constant canonical form) is arguably only achieved if we remove all
+derived data such as the last-modified revision from the inventory itself. That
+said, the last-modified appears to be in a higher level than raw serialization.
+So in the medium term we will not alter the contents of inventories, only the
+way that the current contents are mapped to and from disk.
+
+
+Layering
+--------
+
+We desire clear and clean layers. Each layer should be as simple as we can make
+it to aid in debugging and performance tuning. So where we can choose to either
+write a complex layer and something simple on top of it, or two layers with
+neither being as complex - then we should consider the latter choice better in
+the absence of compelling reasons not to.
+
+Some key layers we have today and can look at using or tweaking are:
+
+ * Tree objects - the abstract interface bzrlib code works in
+ * VersionedFiles - the optionally delta compressing key->bytes storage
+ interface.
+ * Inventory - the abstract interface that many tree operations are written in.
+
+These layers are probably sufficient with minor tweaking. We may want to add
+additional modules/implementations of one or more layers, but that doesn't
+really require new layers to be exposed.
+
+Design elements to achieve the goals in a future inventory implementation
+-------------------------------------------------------------------------
+
+ * Split up the logical document into smaller serialised fragements. For
+ instance hash buckets or nodes in a tree of some sort. By serialising in
+ smaller units, we can increase the number of smaller units rather than
+ their size as the tree grows; as long as two similar trees have similar
+ serialised forms, the amount of different content should be quite high.
+
+ * Use fragment identifiers that are independent of revision id, so that
+ serialisation of two related trees generates overlap in the keyspace
+ for fragments without requiring explicit delta logic. Content Hash Keys
+ (e.g. ('sha1:ABCDEF0123456789...',) are useful here because of the ability
+ to assign them without reference to history.)
+
+ * Store the fragments in our existing VersionedFiles store. Adding an index
+ for them. Have the serialised form be uncompressed utf8, so that delta logic
+ in the VersionedFiles layer can be used. We may need to provide some sort
+ of hinting mechanism to get good compression - but the trivially available
+ zlib compression of knits-with-no-deltas is probably a good start.
+
+ * Item_keys_introduced_by is innately a history-using function; we can
+ reproduce the text-key finding logic by doing a tree diff between any tree
+ and an older tree - that will limit the amount of data we need to process
+ to something proportional to the difference and the size of each fragment.
+ When checking many versions we can track which fragments we have examined
+ and only look at new unique ones as each version is examined in turn.
+
+ * Working tree to arbitrary history revision deltas/comparisons can be scaled
+ up by doing a two-step (fixed at two!) delta combining - delta(tree, basis)
+ and then combine that with delta(basis, arbitrary_revision) using the
+ repositories ability to get a delta cheaply.
+
+ * The key primitives we need seem to be:
+ * canonical_form(inventory) -> fragments
+ * delta(inventory, inventory) -> inventory_delta
+ * apply(inventory_delta, canonical_form) -> fragments
+
+ * Having very many small fragments is likely to cause a high latency
+ multiplier unless we are careful.
+
+ * Possible designs to investigate - a hash bucket approach, radix trees,
+ B+ trees, directory trees (with splits inside a directory?).
+
+
+Hash bucket based inventories
+=============================
+
+Overview
+--------
+
+We store two maps - fileid:inventory_entry and path:fileid, in a stable
+hash trie, stored in densly packed fragments. We pack keys into the map
+densely up the tree, with a single canonical form for any given tree. This is
+more stable than simple fixed size buckets, which prevents corner cases where
+the tree size varies right on a bucket size border. (Note that such cases are
+not a fatal flaw - the two forms would both be present in the repository, so
+only a small amount of data would be written at each transition - but a full
+tree reprocess would be needed at each tree operation across the boundary, and
+thats undesirable.)
+
+Goal satisfaction
+-----------------
+
+ 1. Success
+ 2. Success
+ 3. Success
+ 4. Success, though each change will need its parents looked up as well
+ so it will be proportional to the changes + the directories above
+ the changed path.
+ 5. Success - looking at the difference against all parents we can determine
+ new keys without reference to the repository content will be inserted
+ into.
+ 6. This probably needs a path->id map, allowing a 2-step lookup.
+ 7. If we allocate buckets by hashing the id, then this is succeed, though,
+ as per 4 it will need recursive lookups.
+ 8. Success
+ 9. Fail - data beyond that currently included in testaments is included
+ in the strong validator.
+
+Issues
+------
+
+ 1. Tuning the fragment size needs doing.
+ 1. Testing.
+ 1. Writing code.
+ 1. Separate root node, or inline into revision?
+ 1. Cannot do 'ls' efficiently in the current design.
+ 1. Cannot detect invalid deltas easily.
+ 1. What about LCA merge of inventories?
+
+Canonical form
+--------------
+
+There are three fragment types for the canonical form. Each fragment is
+addressed using a Content Hash Key (CHK) - for instance
+"sha1:12345678901234567890".
+
+root_node: (Perhaps this should be inlined into the revision object).
+HASH_INVENTORY_SIGNATURE
+path_map: CHK to root of path to id map
+content_map: CHK to root of id to entry map
+
+map_node: INTERNAL_NODE or LEAF_NODE
+INTERNAL_NODE:
+INTERNAL_NODE_SIGNATURE
+hash_prefix: PREFIX
+prefix_width: INT
+PREFIX CHK TYPE SIZE
+PREFIX CHK TYPE SIZE ...
+
+(Where TYPE is I for internal or L for leaf).
+
+leaf_node:
+LEAF_NODE_SIGNATURE
+hash_prefix: PREFIX
+HASH\x00KEY\x00 VALUE
+
+For path maps, VALUE is::
+ fileid
+
+For content maps, VALUE::
+ fileid basename kind last-changed kind-specific-details
+
+
+The path and content maps are populated simply by serialising every inventory
+entry and inserting them into both the path map and the content map. The maps
+start with just a single leaf node with an empty prefix.
+
+
+Apply
+-----
+
+Given an inventory delta - a list of (old_path, new_path, InventoryEntry)
+items, with a None in new_path indicating a delete operation, and recursive
+deletes not being permitted - all entries to be deleted must be explicitly
+listed, we can transform a current inventory directly. We can't trivially
+detect an invalid delta though.
+
+To perform an application, naively we can just update both maps. For the path
+map we would remove all entries where the paths in the delta do not match, then
+insert those with a new_path again. For the content map we would just remove
+all the fileids in the delta, then insert those with a new_path that is not
+None.
+
+Delta
+-----
+
+To generate a delta between two inventories, we first generate a list of
+altered fileids, and then recursively look up their parents to generate their
+old and new file paths.
+
+To generate the list of altered file ids, we do an entry by entry comparison of
+the full contents of every leaf node that the two inventories do not have in
+common. To do this, we start at the root node, and follow every CHK pointer
+that is only in one tree. We can then bring in all the values from the leaf
+nodes and do a set difference to get the altered ones, which we would then
+parse.
+
+
+Radix tree based inventories
+============================
+
+Overview
+--------
+
+We store two maps - fileid:path and path:inventory_entry. The fileid:path map
+is a hash trie (as file ids have no useful locality of reference). The
+path:inventory_entry map is stored as a regular trie. As for hash tries we
+define a single canonical representation for regular tries similar to that
+defined above for hash tries.
+
+Goal satisfaction
+-----------------
+
+ 1. Success
+ 2. Success
+ 3. Success
+ 4. Success
+ 5. Success - looking at the difference against all parents we can determine
+ new keys without reference to the repository content will be inserted
+ into.
+ 6. Success
+ 7. Success
+ 8. Success
+ 9. Fail - data beyond that currently included in testaments is included
+ in the strong validator.
+
+Issues
+------
+
+ 1. Tuning the fragment size needs doing.
+ 1. Testing.
+ 1. Writing code.
+ 1. Separate root node, or inline into revision?
+ 1. What about LCA merge of inventories?
+
+Canonical form
+--------------
+
+There are five fragment types for the canonical form:
+
+The root node, hash trie internal and leaf nodes as previous.
+
+Then we have two more, the internal and leaf node for the radix tree.
+
+radix_node: INTERNAL_NODE or LEAF_NODE
+
+INTERNAL_NODE:
+INTERNAL_NODE_SIGNATURE
+prefix: PREFIX
+suffix CHK TYPE SIZE
+suffix CHK TYPE SIZE ...
+
+(Where TYPE is I for internal or L for leaf).
+
+LEAF_NODE:
+LEAF_NODE_SIGNATURE
+prefix: PREFIX
+suffix\x00VALUE
+
+For the content map we use the same value as for hashtrie inventories.
+
+
+Node splitting and joining in the radix tree are managed in the same fashion as
+as for the internal nodes of the hashtries.
+
+
+Apply
+-----
+
+Apply is implemented as for hashtries - we just remove and reinsert the
+fileid:paths map entries, and likewise for the path:entry map. We can however
+cheaply detect invalid deltas where a delete fails to include its children.
+
+Delta
+-----
+
+Delta generation is very similar to that with hash tries, except we get the
+path of nodes as part of the lookup process.
+
+
+Hash Trie details
+=================
+
+The canonical form for a hash trie is a tree of internal nodes leading down to
+leaf nodes, with no node exceeding some threshold size, and every node
+containing as much content as it can, but no leaf node containing less than
+its lower size threshold. (In the event that an imbalance in the hash function
+causes a tree where an internal node is needed, but any prefix generates a
+child with less than the lower threshold, the smallest prefix should be taken).
+An internal node holds some number of key prefixes, all with the same bit-width.
+A leaf node holds the actual values. As trees do not spring fully-formed, the
+canonical form is defined iteratively - by taking every item in a tree and
+inserting it into a new tree in order you can determine what canonical form
+would look like. As that is an expensive operation, it should only be done
+rarely.
+
+Updates to a tree that is in canonical form can be done preserving canonical
+form if we can prove that our rules for insertion are order-independent,
+and that our rules for deletion generate the same tree as if we never
+inserted those nodes.
+
+Our hash tries are balanced vertically but not horizontally. That is, one leg
+of a tree can be arbitrarily deeper than adjacent legs. We require that each
+node along a path within the tree be densely packed, with the densest nodes
+near the top of the tree, and the least dense at the bottom. Except where the
+tree cannot support it, no node is smaller than a minimum_size, and none
+larger than maximum_size. The minimum size constraint is only applied when
+there are enough entries under a prefix to meet that minimum. The maximum
+size constraint is always applied except when a node with a single entry
+is larger than the maximum size. Loosely, the maximum size constraint wins
+over the minimum size constraint, and if the minimum size contraint is to
+be ignored, a deeper prefix can be chosen to pack the containing node more
+densely, as long as no additional minimum sizes checks on child nodes are
+violated.
+
+Insertion
+---------
+
+#. Hash the entry, and insert the entry in the leaf node with a matching
+ prefix, creating that node and linking it from the internal node containing
+ that prefix if there is no appropriate leaf node.
+#. Starting at the highest node altered, for all altered nodes, check if it has
+ transitioned across either size boundary - 0 < min_size < max_size. If it
+ has not, proceed to update the CHK pointers.
+#. If it increased above min_size, check the node above to see if it can be
+ more densely packed. To be below the min_size the node's parent must
+ have hit the max size constraint and been forced to split even though this
+ child did not have enough content to support a min_size node - so the prefix
+ chosen in the parent may be shorter than desirable and we may now be able
+ to more densely pack the parent by splitting the child nodes more. So if the
+ parent node can support a deeper prefix without hitting max_size, and the
+ count of under min_size nodes cannot be reduced, the parent should be given
+ a deeper prefix.
+#. If it increased above max_size, shrink the prefix width used to split out
+ new nodes until the node is below max_size (unless the prefix width is
+ already 1 - the minimum).
+ To shrink the prefix of an internal node, create new internal nodes for each
+ new prefix, and populate them with the content of the nodes which were
+ formerly linked. (This will normally bubble down due to keeping densely
+ packed nodes).
+ To shrink the prefix of a leaf node, create an internal node with the same
+ prefix, then choose a width for the internal node such that the contents
+ of the leaf all fit into new leaves obeying the min_size and max_size rules.
+ The largest prefix possible should be chosen, to obey the
+ higher-nodes-are-denser rule. That rule also gives room in leaf nodes for
+ growth without affecting the parent node packing.
+#. Update the CHK pointers - serialise every altered node to generate a CHK,
+ and update the CHK placeholder in the nodes parent; then reserialise the
+ parent. CHK pointer propagation can be done lazily when many updates are
+ expected.
+
+Multiple versions of nodes for the same PREFIX and internal prefix width should
+compress well for the same tree.
+
+
+Inventory deltas
+================
+
+An inventory is a serialization of the in-memory inventory delta. To serialize
+an inventory delta, one takes an existing inventory delta and the revision_id
+of the revision it was created it against and the revision id of the inventory
+which should result by applying the delta to the parent. We then serialize
+every item in the delta in a simple format:
+
+'format: bzr inventory delta v1 (1.14)' NL
+'parent:' SP BASIS_INVENTORY NL
+'version:' SP NULL_OR_REVISION NL
+'versioned_root:' SP BOOL NL
+'tree_references:' SP BOOL NL
+DELTA_LINES
+
+DELTA_LINES ::= (DELTA_LINE NL)*
+DELTA_LINE ::= OLDPATH NULL NEWPATH NULL file-id NULL PARENT_ID NULL LAST_MODIFIED NULL CONTENT
+SP ::= ' '
+BOOL ::= 'true' | 'false'
+NULL ::= \x00
+OLDPATH ::= NONE | PATH
+NEWPATH ::= NONE | PATH
+NONE ::= 'None'
+PATH ::= path
+PARENT_ID ::= FILE_ID | ''
+CONTENT ::= DELETED_CONTENT | FILE_CONTENT | DIR_CONTENT | TREE_CONTENT | LINK_CONTENT
+DELETED_CONTENT ::= 'deleted'
+FILE_CONTENT ::= 'file' NULL text_size NULL EXEC NULL text_sha1
+DIR_CONTENT ::= 'dir'
+TREE_CONTENT ::= 'tree' NULL tree-revision
+LINK_CONTENT ::= 'link' NULL link-target
+BASIS_INVENTORY ::= NULL_OR_REVISION
+LAST_MODIFIED ::= NULL_OR_REVISION
+NULL_OR_REVISION ::= 'null:' | REVISION
+REVISION ::= revision-id-in-utf8-no-whitespace
+EXEC ::= '' | 'Y'
+
+DELTA_LINES is lexicographically sorted.
+
+Some explanation is in order. When NEWPATH is 'None' a delete has been
+recorded, and because this inventory delta is not attempting to be a reversible
+delta, the only other valid fields are OLDPATH and 'file-id'. PARENT_ID is ''
+when a delete has been recorded or when recording a new root entry.
+
+
+Delta consistency
+=================
+
+Inventory deltas and more broadly changes between trees are a significant part
+of bzr's core operations: they are key components in status, diff, commit,
+and merge (although merge uses tree transform, deltas contain the changes that
+are applied to the transform). Our ability to perform a given operation depends
+on us creating consistent deltas between trees. Inconsistent deltas lead to
+errors and bugs, or even just unexpected conflicts.
+
+An inventory delta is a transform to change an inventory A into another
+inventory B (in patch terms its a perfect patch). Sometimes, for instance in a
+regular commit, inventory B is known at the time we create the delta. Other
+times, B is not known because the user is requesting that some parts of the
+second inventory they have are masked out from consideration. When this happens
+we create a delta that when applied to A creates a B we haven't seen in total
+before. In this situation we need to ensure that B will be internally
+consistent. Deltas are unidirectional, a delta(A, B) creates B from A, but
+cannot be used to create A from B.
+
+Deltas are expressed as a list of (oldpath, newpath, fileid, entry) tuples. The
+fileid, entry elements are normative; the old and new paths are strong hints
+but not currently guaranteed to be accurate. (This is a shame and something we
+should tighten up). Deltas are required to list all removals explicitly -
+removing the parent of an entry doesn't remove the entry.
+
+Applying a delta to an inventory consists of:
+ - removing all fileids for which entry is None
+ - adding or replacing all other fileids
+ - detecting consistency errors
+
+An interesting aspect of delta inconsistencies is when we notice them:
+ - Silent errors which our application logic misses
+ - Visible errors we catch during application, so bad data isn't stored in
+ the system.
+
+The minimum safe level for our application logic would be to catch all errors
+during application. Making generation never generate inconsistent deltas is
+a seperate but necessary condition for robust code.
+
+An inconsistent delta is one which:
+ - after application to an inventory the inventory is an impossible state.
+ - has the same fileid, or oldpath(not-None), or newpath(not-None) multiple
+ times.
+ - has a fileid field different to the entry.fileid in the same item in the
+ delta.
+ - has an entry that is in an impossible state (e.g. a directory with a text
+ size)
+
+Forms of inventory inconsistency deltas can carry/cause:
+ - An entry newly introduced to a path without also removing or relocating any
+ existing entry at that path. (Duplicate paths)
+ - An entry whose parent id isn't present in the tree. (Missing parent).
+ - Having oldpath or newpath not be actual original path or resulting path.
+ (Wrong path)
+ - An entry whose parent is not a directory. (Under non-directory).
+ - An entry that is internally inconsistent.
+ - An entry that is already present in the tree (Duplicate id)
+
+Known causes of inconsistency:
+ - A 'new' entry which the inventory already has - when this is a directory
+ even arbitrary file ids under the 'new' entry are more likely to collide on
+ paths.
+ - Removing a directory without recursively removing its children - causes
+ Missing parent.
+ - Recording a change to an entry without including all changed entries found
+ following its parents up to and includin the root - can cause duplicate
+ paths, missing parents, wrong path, under non-directory.
+
+Avoiding inconsistent deltas
+----------------------------
+
+The simplest thing is to never create partial deltas, as it is trivial to
+be consistent when all data is examined every time. However users sometimes
+want to specify a subset of the changes in their tree when they do an operation
+which needs to create a delta - such as commit.
+
+We have a choice about handling user requests that can generate inconsistent
+deltas. We can alter or interpret the request in such a way that the delta will
+be consistent, but perhaps larger than the user had intended. Or we can
+identify problematic situations and abort, specifying to the user why we have
+aborted and likely things they can do to make their request generate a
+consistent delta.
+
+Currently we attempt to expand/interpret the request so that the user is not
+required to understand all the internal constraints of the system: if they
+request 'foo/bar' we automatically include foo. This works but can surprise
+the user sometimes when things they didn't explicitly request are committed.
+
+Different trees can use different algorithms to expand the request as long as
+they produce consistent deltas. As part of getting a consistent UI we require
+that all trees expand the paths requested downwards. Beyond that as long as
+the delta is consistent it is up to the tree.
+
+Given two trees, source and target, and a set of selected file ids to check for
+changes and if changed in a delta between them, we have to expand that set by
+the following rules, to get consistent deltas. The test for consistency is that
+if the resulting delta is applied to source, to create a third tree 'output',
+and the paths in the delta match the paths in source and output, only one file
+id is at each path in output, and no file ids are missing parents, then the
+delta is consistent.
+
+Firstly, the parent ids to the root for all of the file ids that have actually
+changed must be considered. Unless they are all examined the paths in the delta
+may be wrong.
+
+Secondly, when an item included in the delta has a new path which is the same
+as a path in source, the fileid of that path in source must be included.
+Failing to do this leads to multiple ids tryin to share a path in output.
+
+Thirdly, when an item changes its kind from 'directory' to anything else in the
+delta, all of the direct children of the directory in source must be included.
diff --git a/doc/developers/last-modified.txt b/doc/developers/last-modified.txt
new file mode 100644
index 0000000..0a92f05
--- /dev/null
+++ b/doc/developers/last-modified.txt
@@ -0,0 +1,176 @@
+==============================
+Computing last_modified values
+==============================
+
+Introduction
+------------
+
+Bazaar (through at least 0.19) computes a ``last_modified``
+attribute for all inventory entries and stores it at commit time.
+This is the ``revision_id`` that last changed or merged the file. It is
+used in knit and weave repositories to look up the file text, and to index
+into the file graph. It's also used to determine which revisions of the
+file text to pull during ``fetch``.
+
+This data is not natively stored by most other systems so we need to
+synthesize it during conversion.
+
+This is a case of non-core data that we might wish to treat as cached,
+rather than always stored.
+
+Definition
+----------
+
+Take the set of all "heads": all the versions of these files in parent
+trees.
+
+Reduce the heads by eliminating any whose last_modified is an ancestor of
+the last_modified of any other head.
+
+If there is still more than one head, a new last_modified is assigned.
+This points to the merge point in the file graph.
+
+If the file text and properties are the same as the sole remaining head,
+its last_modified is inherited. Property changes include executable bit,
+filename, and containing directory.
+
+Otherwise, a new last_modified is used.
+
+(This is meant to be the simplest statement, but it may not be the most
+efficient algorithm; anything that gives equivalent results can be used.)
+
+
+Generation in commit
+--------------------
+
+Commit and converters both need this when writing into Bazaar native
+formats.
+
+This is an O(tree) operation because it needs to check for files with
+multiple heads. It could be reduced to O(changed_or_merged_files) if that
+was faster to determine. So it needs to be fast.
+
+For the single-parent commit case, we just need to determine which files have
+changed compared to the parent. If the file was changed, it gets the
+revision id of the new revision; otherwise it inherits the value from the
+parent tree.
+
+In the multi-parent commit case (commit of a merge), it can take the value
+from any of the parent trees, or of the new revision.
+
+Commit in a dirstate tree should be able to do this more easily by looking
+at a row of the dirstate to get the per-file parents. It still needs to
+look at the revision or file graph information to work out whether heads can be
+eliminated as previously merged. At the moment ``find_previous_heads`` works on
+inventories, so needs to spend considerable effort building whole
+inventories, including files that are not modified or merged. (Called
+from ``record_entry_contents``.) It might be better to have the commit
+builder pass in the per-entry parents so that dirstate can generate just
+those that are necessary. (See also the spec for
+``iter_changes_multiple_parents``.)
+
+If merge used a per-file graph then it would know when one version fully
+supersedes another, and it could emit only a single parent. Merge could
+in fact do this even when not using per-file graphs. In the current
+dirstate format we need to store the full data for all trees because they
+can be extracted from the dirstate, but it could mark some parents as
+already merged.
+
+Alternatively, we could change the dirstate to include
+only the base and current trees, and cache the merged-in parents
+elsewhere.
+
+(Offtopic other dirstate changes: we could also omit the working-copy
+hash, and just have a stat-fingerprint of when it was last known equal to
+the basis revision. That reduces the amount of data stored and possibly
+makes it simpler to update, and shouldn't penalize common cases.)
+
+
+Generation during conversion
+----------------------------
+
+Accessing a foreign branch requires synthesizing this information.
+If last_modified is removed from a future bzr version, we will also need
+to synthesize it to pull back to earlier formats.
+
+Because last_modified is not natively stored in the foreign branches, we
+want to take advantage of any conversion we've already done, so that we
+don't need to recursively generate them on every access. We'd
+prefer to find a revision that's already converted to a Bazaar inventory
+within another related repository, such as the target of a conversion.
+
+
+Avoiding last_modified
+----------------------
+
+last_modified is potentially expensive to determine and we may not want to
+store it in inventories in future. Therefore we should use it only when
+necessary:
+
+* When writing out an inventory format that includes it.
+
+* In Bazaar formats that use it as a key for the file text or file
+ ancestry. This should be hidden behind the Repository/RevisionTree
+ interface.
+
+* When a user operation specifically requires the last_modified (e.g.
+ hypothetical annotate directory).
+
+We already do this in most cases.
+
+
+Compared to annotate
+--------------------
+
+
+Use cases
+---------
+
+Cases to test
+-------------
+
+1. Single parent, unmodified file
+2. Single parent, modified file
+3. Two parents, one descended from the other, modified in one parent only
+4. Two parents, one descended from the other, modified in one parent only,
+ but also modified locally.
+5. Two parents, not descended from each other, modified in one parent only.
+6. Two parents, not descended from each other, modified in one parent only,
+ but also modified locally.
+7. Two parents, modified in both to different values.
+8. Two parents, modified in both to the same value.
+9. Two parents, modified in both, and reverted in both back to the
+ original text.
+10. Three parents, modified in only one
+11. Three parents, modified in only one, also modified locally.
+12. Three parents, modified in 2
+13. Three parents, modified in 2, and locally.
+14. Three parents, modified in 2, but one is a descendant of the other.
+
+
+
+Performance considerations
+--------------------------
+
+Often we'll want the last_modified information for multiple files, perhaps
+everything in a directory or in a whole tree. It may be more efficient
+for the api to accommodate this. Often the last_modified will be similar
+for multiple files, and if we process them all at once we can avoid some
+repeated work in calculating their heads.
+
+
+Open questions
+--------------
+
+* How does caching ``find_heads`` interact with cherry-picks?
+
+
+
+Possible structure
+==================
+
+For a single file, if I am different from all parents, 'new'. (Do not need
+to evaluate last modified).
+
+..
+ vim: ft=rst tw=74
diff --git a/doc/developers/lca-merge.txt b/doc/developers/lca-merge.txt
new file mode 100644
index 0000000..7d6b07c
--- /dev/null
+++ b/doc/developers/lca-merge.txt
@@ -0,0 +1,175 @@
+LCA Merge
+=========
+
+by Aaron Bentley
+
+Essential characteristics
+-------------------------
+
+In the general case (no criss-cross), it is a three-way merge. When
+there is a criss-cross at the tree level, but not for the particular
+file, it is still a three-way merge. When there's a file-level
+criss-cross, it's superior to a three-way merge.
+
+Algorithm
+---------
+
+First, we compare the files we are trying to merge, and find the lines
+that differ. Next, we try to determine why they differ; this is
+essential to the merge operation, because it affects how we resolve the
+differences. In this merger, there are three possible outcomes:
+
+1. The line was added in this version: "new-this"
+2. The line was deleted in the other version: "killed-other"
+3. The line was preserved as part of merge resolution in this version,
+ but deleted in the other version: "conflicted-this"
+
+Option 3 is new, but I believe it is essential. When each side has made
+a conflicting merge resolution, we should let the user decide how to
+combine the two resolutions, i.e. we should emit a conflict. We cannot
+silently drop the line, or silently keep the line, which can happen if
+we choose options 1 or 2. If we choose options 1 or 2, there's also a
+possibility that a conflict will be produced, but no guarantee. We need
+a guarantee, which is why we need a new possible outcome.
+
+To decide whether a line is "new-this", "killed-other" or
+"conflicted-this", we compare this version against the versions from
+each "least common ancestor" (LCA), in graph terminology. For each LCA
+version, if the line is not present in the LCA version, we add it to the
+"new" set. If the line is present in the LCA version, we add it to the
+"killed" set.
+
+When we are done going through each LCA version, each unique line will
+be in at least one of the sets. If it is only in the "new" set, it's
+handled as "new-this". If it is only in the "killed" set, it's handled
+as "killed-other". If it is in both sets, it's handled as
+"conflicted-this".
+
+The logic here is a bit tricky: first, we know that the line is present
+in some, but not all, LCAs. We can assume that all LCAs were produced
+by merges of the same sets of revisions. That means that in those LCAs,
+there were different merge resolutions. Since THIS and OTHER disagree
+about whether the line is present, those differences have propagated
+into THIS and OTHER. Therefore, we should declare that the lines are in
+conflict, and let the user handle the issue.
+
+LCA merge and Three-way merge
+-----------------------------
+
+Now, in the common case, there's a single LCA, and LCA merge behaves as
+a three-way merge. Since there's only one LCA, we cannot get the
+"conflicted-this" outcome, only "new-this" or "killed-other. Let's look
+at the typical description of three-way merges:
+
++-----+------+-------+------------+
+|THIS | BASE | OTHER | OUT |
++-----+------+-------+------------+
+|A | A | A | A |
++-----+------+-------+------------+
+|A | B | A | A |
++-----+------+-------+------------+
+|A | B | B | A |
++-----+------+-------+------------+
+|A | A | B | B |
++-----+------+-------+------------+
+|A | B | C |\*conflict\*|
++-----+------+-------+------------+
+
+Now, let's assume that BASE is a common ancestor, as is typically the
+case. In fact, for best-case merges, BASE is the sole LCA.
+
+We always pick the version that represents a change from BASE, if there
+is one. For the AAAA line, there is no change, so the output is
+rightfully BASE/THIS/OTHER. For ABAA, the THIS and OTHER are changes
+from BASE, and they are the same change so they both win. (This case is
+sometimes called convergence.) For ABBA, THIS is a change from BASE, so
+THIS wins. For AABB, OTHER is a change from BASE, so OTHER wins. For
+ABC*, THIS and OTHER are both changes to BASE, but they are different
+changes, so they can't both win cleanly. Instead, we have a conflict.
+
+Now in three-way merging, we typically talk about regions of text. In
+weave/knit/newness/lca merge, we also have regions. Each contiguous
+group of "unchanged" lines is a region, and the areas between them are
+also regions.
+
+Let's assign a to THIS and b to OTHER. "unchanged" regions represent
+the AAAA or ABAA cases; it doesn't matter which, because the outcome is
+the same regardless. Regions which consist of only "new-a" or
+"killed-a" represent the ABBA case. Regions which consist of only
+"new-b" or "killed-b" represent the AABB case. Regions which have
+(new-a or killed-a) AND (new-b or killed-b) are the ABC* case-- both
+sides have made changes, and they are different changes, so a conflict
+must be emitted.
+
+This is what I mean when I say that it is a three-way merge in the
+common case; if there is only one LCA, then it is merely an alternative
+implementation of three-way. (One that happens to automatically do
+``--reprocess``, ftw).
+
+Exception to three-way behavior
+-------------------------------
+There is a special case of three-way merge which LCA merge handles differently
+from our default "merge3" algorithm:
+BASE has content X, THIS deletes the content, and OTHER changes X to Y. In
+this case, LCA merge emits Y in its output and does not indicate a conflict.
+merge3 would output Y, but would also indicate a conflict. (This is also the
+behavior in the inverse case where OTHER has nothing and THIS has Y.)
+
+This behavior is due the way LCA determines basic conflicts; they
+can only be emitted when THIS and OTHER each have unique lines between common
+lines. If THIS does not have unique lines in this position, conflicts will not
+be emitted, even if its (lack of) content is unique.
+
+This behavior difference is shared with "weave" merge. I hope that a future
+revision of LCA merge will handle this case as merge3 would.
+
+Why a new name
+--------------
+
+1. It was time. Although knit / annotate merge and newness merge have
+ tried to emulate the behavior of the original weave merge algorithm,
+ ``--merge-type=weave`` hasn't been based on weaves for a long time.
+2. Behavior differences. This algorithm should behave like a three-way
+ merge in the common case, while its predecessors did not. It also has
+ explicit support for handling conflicting merge resolutions, so it
+ should behave better in criss-cross merge scenarios.
+
+Performance
+-----------
+
+Unlike the current "weave" merge implementation, lca merge does not
+perform any whole-history operations. LCA selection should scale with
+the number of uncommon revisions. Text comparison time should scale
+mO(n\ :sup:`2`\ ), where m is the number of LCAs, and n is the number of lines
+in the file. The current weave merge compares each uncommon ancestor,
+potentially several times, so it is >= kO(n\ :sup:`2`\ ), where k is the
+number of uncommon ancestors. So "lca" should beat "weave" both in history
+analysis time and in text comparison time.
+
+Possible flaws
+==============
+
+1. Inaccurate LCA selection. Our current LCA algorithm uses
+ ``Graph.heads()``, which is known to be flawed. It may occasionally give
+ bad results. This risk is mitigated by the fact that the per-file graphs
+ tend to be simpler than the revision graph. And since we're already using
+ this LCA algorithm, this is not an additional risk. I hope that John Meinel
+ will soon have a fixed version of ``Graph.heads`` for us.
+2. False matches. Weaves have a concept of line identity, but knits and
+ later formats do not. So a line may appear to be common to two files, when
+ in fact it was introduced separately into each for entirely different
+ reasons. This risk is the same for three-way merging. It is mitigated by
+ using Patience sequence matching, which a longest-common-subsequence match.
+
+Acknowledgements
+================
+
+I think this could be a great merge algorithm, and a candidate to make
+our default, but this work would not have been possible without the work
+of others, especially:
+
+- Martin Pool's weave merge and knit/annotate merge algorithms.
+- Bram Cohen's discussions of merge algorithms
+- Andrew Tridgell's dissection of BitKeeper merge
+- Nathaniel Smith's analysis of why criss-cross histories necessarily
+ produce poor three-way merges.
diff --git a/doc/developers/lca_tree_merging.txt b/doc/developers/lca_tree_merging.txt
new file mode 100644
index 0000000..f1693e6
--- /dev/null
+++ b/doc/developers/lca_tree_merging.txt
@@ -0,0 +1,126 @@
+================
+LCA Tree Merging
+================
+
+There are 2 ways that you get LCA merge resolution in bzr. First, if you use
+``bzr merge --lca``, the *content* of files will be resolved using a Least Common
+Ancestors algorithm. That is described in <lca-merge.html> not here.
+
+This document describes how we handle merging tree-shape when there is not
+a single unique ancestor (criss-cross merge). With a single LCA, we use
+simple 3-way-merge logic.
+
+When there are multiple possible LCAs, we use a different algorithm for
+handling tree-shape merging. Described here.
+
+As a simple example, here is a revision graph which we will refer to often::
+
+ . BASE
+ . / \
+ . LCA1 LCA2
+ . | \ / |
+ . | X |
+ . | / \ |
+ . THIS OTHER
+
+In this graph, ``THIS`` and ``OTHER`` both have ``LCA1`` and ``LCA2`` in their
+ancestry but neither is an ancestor of the other, so we have 2 least common
+ancestors. The unique common ancestor is ``BASE``. (It should be noted that in
+this text we will talk directly about ``LCA1`` and ``LCA2``, but the algorithms
+are designed to cope with more than 2 LCAs.)
+
+
+Scalars
+=======
+
+Definition
+----------
+
+I'm defining scalar values as ones that cannot be 'merged' on their own. For
+example, the name of a file is "scalar". If one person changes "foo.txt" to
+"foo.c" and someone else changes "foo.txt" to "bar.txt" we don't merge the
+changes to be "bar.c", we simply conflict and expect the user to sort it out.
+
+We use a slightly different algorithm for scalars.
+
+
+Resolution Algorithm
+--------------------
+
+(This can be seen as ``bzrlib.merge.Merge3Merger._lca_multi_way```
+
+1. If ``THIS`` and ``OTHER`` have the same value, use it. There is no need to
+ inspect any other values in this case. Either nothing was changed (all
+ interesting nodes would have the same value), or we have "accidental
+ convergence" (both sides made the same change.).
+
+2. Find the values from ``LCA1`` and ``LCA2`` which are not the same as
+ ``BASE``. The idea here is to provide a rudimentary "heads" comparison.
+ Often, the whole tree graph will have a criss-cross, but the per-file
+ (per-scalar) graph would be linear, and the value in one LCA strictly
+ dominates the other. It is possible to construct a scenario where one side
+ dominates the other, but the dominated value is not ``BASE``, but a second
+ intermediate value. Most scalars are rarely changed, so this is unlikely to
+ be an issue. The trade-off is having to generate and inspect the
+ per-scalar graph.
+
+ If there are no LCA values that are different from ``BASE``, we use a simple
+ 3-way merge with ``BASE`` as the base value.
+
+3. Find the unique set of LCA values that do not include the ``BASE`` value.
+ If there is only one unique LCA value, we again use three-way merge logic
+ using that unique value as the base.
+
+4. At this point, we have determined that we have at least 2 unique values in
+ our LCAs which means that ``THIS`` and ``OTHER`` would both have to resolve
+ the conflict. If they resolved it in the same way, we would have caught that
+ in step 1. So they either both picked a different LCA value, or one (or
+ both) chose a new value to use.
+
+ If ``OTHER`` and ``THIS`` both picked a different LCA value, we conflict.
+
+ If ``OTHER`` and ``THIS`` both have values that are not LCA values, we also
+ conflict. (Same as 3-way, both sides modified a value in different ways.)
+
+5. (optional) The only tricky part is this: if ``OTHER`` has a LCA value, but
+ ``THIS`` does not, then we go with ``THIS``, and conversely if ``THIS`` has
+ an LCA value, but ``OTHER`` does not, then we go with ``OTHER``. The idea is
+ that ``THIS`` and ``OTHER`` may have resolved things in the same way, and
+ then later changed the value to something newer. (They could have also
+ resolved it differently, and then one side updated again.)
+
+
+``InventoryEntry.revision``
+---------------------------
+
+The last-modified revision for an entry gets treated differently. This is
+because how it is generated allows us to infer more information. Specifically,
+any time there is a change to an entry (rename, or content change) the last
+modified revision is updated. Further, if we are merging, and both sides
+updated the entry, then we update the last-modified revision at the merge
+point.
+
+For a picture example::
+
+ . A
+ . / \
+ . B C
+ . \ /
+ . D
+
+
+For a single entry, the last modified revision in ``D`` is:
+
+1) ``A`` if neither ``B`` or ``C`` modified it
+2) ``B`` if ``B`` modified and ``C`` did not
+3) ``C`` if ``C`` modified and ``B`` did not
+4) ``D`` if ``B`` and ``C`` modified it
+
+This means that if the last modified revision is the same, there have been no
+changes in the intermediate time. If ``OTHER`` also has the same last modified
+revision as *any* LCA, then we know that all other LCAs' last-modified
+revisions are in the ancestry of that value. (Otherwise, when ``OTHER`` would
+need to create a new last modified revision as part of the merge.)
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/merge-scaling.txt b/doc/developers/merge-scaling.txt
new file mode 100644
index 0000000..ee25c61
--- /dev/null
+++ b/doc/developers/merge-scaling.txt
@@ -0,0 +1,35 @@
+Scaling analysys of Merge
+=========================
+
+1. Fetch revisions O(a)
+2. Common Ancestor [O(b)] **O(h)**
+3. Calculate tree merge O(c) [+ O(b) + O(d)] **+ O(i)**
+
+ - text merge O(e * e * f) + O(b)
+
+4. Find filesystem conflicts O(c)
+5. Resolve filesystem conflicts O(g)
+6. Apply changes O(c) + O(log(d))
+7. Set pending merges O(1)
+8. Print conflicts O(g)
+9. Print changes O(c)
+
+:a: revisions missing from repo:
+:b: nodes in the revision graph:
+:c: files that differ between base and other:
+:d: number of files in the tree
+:e: number of lines in the text
+:f: number of files requiring text merge
+:g: number of conflicts (g <= c)
+:h: humber of uncommon ancestors
+:i: number of revisions between base and other
+
+Needs
+-----
+- Access to revision graph proportional to number of revisions read
+- Access to changed file metadata proportional to number of changes and number of intervening revisions.
+- O(1) access to fulltexts
+
+Notes
+-----
+Multiparent deltas may offer some nice properties for performance of annotation based merging.
diff --git a/doc/developers/miscellaneous-notes.txt b/doc/developers/miscellaneous-notes.txt
new file mode 100644
index 0000000..672f0e1
--- /dev/null
+++ b/doc/developers/miscellaneous-notes.txt
@@ -0,0 +1,20 @@
+Miscellaneous notes
+===================
+
+.. toctree::
+ :hidden:
+
+ dirstate
+ update
+
+
+* `dirstate <dirstate.html>`_ |--| An observation re. the dirstate file
+
+* `"bzr update" performance analysis <update.html>`_ |--| "bzr update"
+ performance analysis
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/missing.txt b/doc/developers/missing.txt
new file mode 100644
index 0000000..c442f1c
--- /dev/null
+++ b/doc/developers/missing.txt
@@ -0,0 +1,27 @@
+Missing
+=======
+
+Missing is used to find out the differences between the current branch and
+another branch.
+
+The performance analysis itself brings no further points than the
+incremental-push-pull one.
+
+More importantly, the UI have been considered not optimal: missing finds and
+displays the differences between two branches, presenting the revisions that
+are not common to both branches as two sets:
+
+* the revisions that are present only in the current branch,
+* the revisions that are present only in the other branch.
+
+A quick and dirty survey indicates that most of the users are interested in
+only one set of revisions at a time.
+
+From a performance point of view, it may be more appropriate to calculate only
+the set the user is asking for.
+
+It has been proposed that the missing command be deprecated in favor of a
+--dry-run option for the push, pull, merge commands.
+
+In the mean time, the missing command stays interesting as it provides an easy
+way to test, measure and optimize graph differences processing.
diff --git a/doc/developers/nested-trees.txt b/doc/developers/nested-trees.txt
new file mode 100644
index 0000000..7c70efb
--- /dev/null
+++ b/doc/developers/nested-trees.txt
@@ -0,0 +1,1023 @@
+************
+Nested Trees
+************
+
+:status: 2012-03-17: Draft spec
+
+.. sectnum::
+
+.. contents::
+
+Principles
+**********
+
+- Never store a location in versioned data.
+
+- Implementation of nested trees shall not make operations observably slower
+ for those not using nested trees.
+
+- A repository that holds a revision R should be able to reconstruct the
+ whole contents of that revision, including any nested trees. Corolary:
+ if I fetch that revision, even into a branch that has no working tree, it
+ should bring across any referenced revisions, or (implicitly) add fallback
+ repositories.
+
+- The introduction or possible support for nested trees should not
+ have an impact on performance.
+
+Core Concepts
+*************
+
+**Subtree** A tree which is inside another tree, which bzr has been asked to
+treat as part of the outer tree.
+
+**Subbranch** The branch associated with a subtree.
+
+**Containing tree** A tree which has another tree inside it
+
+**Tree reference** A directory in a containing tree which contains a subtree.
+
+
+Basic design approach
+*********************
+(see "Design decisions" for extended rationale)
+By default, APIs and commands for containing trees should behave as though the
+subtrees were plain directories. By default, commands in subtrees should not
+affect the containing trees.
+
+Downwards recursion
+~~~~~~~~~~~~~~~~~~~
+One of the objectives of nested trees is to provide ways of reproducing
+historical combinations of different codebases. The dependency chain points
+downwards, such that trees are affected by the revision of their subtrees, but
+subtrees are oblivious to their containing trees. Just as bazaar doesn't
+entice people to commit inconsistent trees, it should not entice people to
+commit inconsistent combinations of containing tree and subtree. Therefore,
+commit should recurse downwards by default.
+
+Status and diff should reflect what will happen when commit is used, so they
+should also recurse downward by default. Add almost does this already. With
+status, diff, commit and add recursing downwards, it would be confusing to
+users if other operations did not. Therefore, all operations should recurse
+downwards by default.
+
+No upwards recursion by default
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+One of the reasons for using nested trees is to gain performance by only
+committing in a subtree. Therefore, operations should not recurse upwards by
+default. However, some users do want to have upwards recursion, so it should
+be provided as an option.
+
+Modelling nested trees as a composite tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The idea that a set of nested trees behaves like a single, larger tree seems
+relatively easy to grasp. Both for users and for developers, it provides a
+clear expectation for the behaviour of nested trees. There are no obvious
+drawbacks in terms of code clarity or performance. Therefore, it seems like a
+good model to start with.
+
+Using root file-ids for tree-references
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The idea that tree-reference file-ids are the same as the file-ids of the
+corresponding root directories has a nice symmetry. It is one way of ensuring
+that "bzr split" is deterministic, and "bzr join" is deterministic. When
+performing operations involving a tree and a split version of that tree, using
+the same file-id makes it easy to ensure that operations such as moves and
+renames are applied appropriately to the tree-reference. Providing mechanisms
+whereby a tree-reference can be treated as it would if it had its old file-id
+encroaches on the territory of path tokens or file-id aliases. Having "split"
+cause file-id changes means that in comparing these revisions, it would be seen
+as a deleting a directory and creating a new tree-reference with the same name.
+Handling this correctly in operations such as merge and revert would be more
+complicated than if it were treated as a kind change, especially when
+unversioned files are present in the subtree.
+
+Sub-branches
+~~~~~~~~~~~~
+The branches associated with subtrees shall be called "subbranches".
+
+The branch for the top tree will be in a special format, whose last_revision
+file lists all the last_revision info for all of the branches associated with
+the nested tree. The .bzr directories of subtrees will have a "branch" that
+simply indicates that the top tree's branch should be used.
+
+In the top tree's last_revision file, the revision id and revno will be
+provided, indexed by the tree-reference file-id.
+
+The repository used by the top-tree's branch must be a shared repository, and
+will be used by the sub-branches.
+
+Only the top branch will have a branch.conf. When an operation on a subbranch
+would normally use values from branch.conf it will look them up in the top
+branch's branch.conf and adjust for the sub-location if appropriate. e.g. "bzr
+push" in a subtree will push just that subbranch to the corresponding subbranch
+in the configured push location of the top branch.
+
+Rationale
+.........
+If the branches were not local, the local subtrees might not be committable,
+and commits to the remote branch would make the local subtree out of date.
+They should not be in a separate location from the containing branch, because
+they might share history with the tree-reference's branch. However, those
+local branches should not be at the same location as their tree, because the
+tree might be deleted or moved. Indeed, they should not be anywhere within a
+working tree.
+
+subtree branches should not be above or beside their containing branch, because
+it could cause terrible confusion if subtrees from two different trees were
+updating the same branches with every push, pull, commit and uncommit.
+
+Subtree branches could be plain branches stored somewhere in the top tree's
+branch, but then a lookup mechanism would be needed to translate from file_id
+to location, and performance with large numbers of subbranches would be poor.
+
+Pull and non-initial push
+~~~~~~~~~~~~~~~~~~~~~~~~~
+When a pull involves updates to tree references, pull will always pull into the
+reference branch. For all new revisions in the upper branch, it will determine
+the revision values of tree references, and fetch them into the repository.
+
+When new tree references are encountered, pull should create a corresponding
+subbranch in the top branch.
+
+Pulls will update the subtrees whose tree-references change, including creating
+trees for new sub-branches.
+
+Implementation strategies
+*************************
+
+Data storage
+************
+
+Trees
+~~~~~
+The root-ids of trees must be unique, so that the same file-id can be used in
+both the containing tree and the subtree, to simplify access within trees.
+Tree references are an inventory type that is distinct from a directory, and
+has a revision-id associated with it.
+All modern working trees support tree references. Indices may be provided to
+ensure fast access to the list of subtrees.
+
+The various methods on ``Tree`` need to be updated to handle nested trees.
+
+Tree file ids are tuples containing inventory file ids, describing a path
+to the file. This means that if a file is in a nested tree with the root
+fileid ``file_id_a`` and the file itself has the inventory file id ``file_id_b``
+then the tree file id is (file_id_a, file_id_b). This makes it easy to look up file ids
+without having to load and scan all nested trees for ``file_id_b``.
+
+Branches
+~~~~~~~~
+A new branch format, "subbranches", is introduced which provides multiple
+sub-branches, with their data referenced by file-id. A new branch refrerence
+format, "subbranch-reference", is introduced which refers to sub-branches in a
+"subbranches" branch.
+
+Repositories
+~~~~~~~~~~~~
+Some repository formats have 'subtree' variants, e.g. pack-0.92-subtree,
+development-subtree. These are hidden, experimental formats that support
+storing tree-references in their inventory formats.
+
+Repository indexing might be extended to provide fast access to
+tree-references.
+
+Commands
+********
+
+The following new options are introduced:
+
+``join --reference`` Cause an inner tree to be treated as a subtree. The outer
+tree's branch must be in the new "subbranches" format. The inner tree's branch
+will be cloned into the "subbranches" branch, and the local branch will be
+replaced with a "subbranch-reference". Finally, a tree-reference will be
+added to the containing tree.
+
+(this is already implemented)
+
+API Changes
+***********
+
+Tree file ids as tuples
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Implementation Changes
+**********************
+
+Branch changes
+~~~~~~~~~~~~~~
+
+ pull recurses into reference branches, and pulls *from* the source's reference
+ branches.
+
+Repository changes
+~~~~~~~~~~~~~~~~~~
+
+ fetch provides a list of tree-reference revision ids/file-id pairs for the
+ revisions that were fetched. Fetch automatically fetches all revisions
+ associted with tree-references that were fetched.
+
+Use Cases
+*********
+
+Case 1
+~~~~~~
+Barry works on a project with three libraries. He wants to keep up to date
+with the tip of those libraries, but he doesn't want them to be part of his
+source tree.
+
+Example commands::
+
+ Set up the tree:
+ $ bzr branch --nested http://library1 project
+ $ bzr branch --nested http://library2 project
+ $ bzr branch --nested http://library3 project
+ $ bzr commit project -m "Added three libraries"
+
+ Update a library to tip:
+ $ bzr pull -d project/library1 http://library1
+
+Case 2
+~~~~~~
+Now, Barry wants to add a fourth library.
+
+Example commands::
+
+ $ bzr branch --nested http://library4 project
+
+Case 3
+~~~~~~
+Barry wants to publish his project.
+
+Example commands::
+
+ $ bzr push -d project bzr+ssh://project/trunk
+
+Case 4
+~~~~~~
+Barry decides to make part of his project into another library
+
+Example commands::
+
+ $ bzr split --nested project/newlibrary
+
+Case 5
+~~~~~~
+Curtis wants to hack on Barry's project
+
+Example commands::
+
+ $ bzr branch http://project/trunk
+
+Case 6
+~~~~~~
+Barry wants to drop one of the libraries he was using
+
+Example commands::
+
+ $ rm project/library1
+ $ bzr commit project -m "Removed library1"
+
+Case 7
+~~~~~~
+Curtis has made changes to one of the libraries. Barry wants to merge Curtis'
+changes into his copy.
+
+Example commands::
+
+ $ bzr merge -d project http://curtis.org/trunk/library2
+
+ Or alternatively:
+ $ bzr merge -d project/library2 http://curtis.org/trunk/library2
+
+Case 8
+~~~~~~
+Curtis has made changes to Barry's main project. Barry wants to merge Curtis'
+changes into his copy.
+
+Example commands::
+
+ $ bzr merge -d project http://curtis.org/trunk
+
+
+Case 9
+~~~~~~
+Barry makes changes in his project and in a library, and he runs status
+
+Example commands::
+
+ $ echo bar > project/foo
+ $ echo qux > project/library2/baz
+ $ bzr status project
+ M foo
+ M library2/baz
+
+Case 10
+~~~~~~~
+Barry wants to upgrade the bazaar format of his project
+
+Example commands::
+
+ $ bzr upgrade project
+
+Case 11
+~~~~~~~
+Curtis wants to apply Barry's latest changes.
+
+Example commands::
+
+ $ bzr merge -d project http://project/trunk
+
+Case 12
+~~~~~~~
+Danilo wants to start a project with two libraries using nested trees from
+scratch.
+
+Example commands::
+
+ $ bzr init project
+ $ bzr branch --nested http://library4 project
+ $ bzr branch --nested http://library5 project
+ $ bzr commit project -m "Created new project."
+
+Case 13
+~~~~~~~
+Edwin has a project that doesn't use nested trees and he wants to start using
+nested trees.
+
+Example commands::
+ $ bzr split --nested project/subdir
+
+Case 14
+~~~~~~~
+Françis has a project with nested trees where the containing tree uses one
+Bazaar format and the subtree uses a different Bazaar format.
+
+Not supported.
+
+Case 15
+~~~~~~~
+Barry commits some changes to a library and to the main project, and then
+discovers the changes are not appropriate. He has not yet pushed his changes
+anywhere.
+
+Example commands::
+
+ $ bzr merge -d project http://library2
+ $ bzr commit project -m "Updated library2"
+ $ bzr uncommit project --force
+
+Case 16
+~~~~~~~
+Barry commits some changes to a library and to the main project, publishes his
+branch, and then discovers the changes are not appropriate.
+
+Example commands::
+
+ $ bzr merge -d project http://library2
+ $ bzr commit project -m "Updated library2"
+ $ bzr push -d project
+ $ bzr revert -r-2 project
+ $ bzr commit project -m "Reverted inappropriate changes."
+ $ bzr push -d project
+
+Case 17
+~~~~~~~
+Gary is writing a project. Henninge wants to split a library out of it.
+
+Example commands::
+
+ $ bzr branch project
+ $ bzr split project/library6
+ $ mv project/library6 .
+ $ rm project
+ $ bzr commit -m "split library6 into its own library."
+
+Case 18
+~~~~~~~
+Henning wants to update to receive Gary's latest changes.
+
+Example commands::
+
+ $ bzr merge -d library6
+
+Case 19
+~~~~~~~
+Gary wants to update to receive Henninge's changes, including splitting a
+library out.
+
+Example commands::
+
+ $ bzr split --nested project/library6
+ $ bzr commit project -m "Turned library6 into a library"
+ $ bzr merge -d project/library6 http://library6
+ $ bzr commit project -m "Merge Henninge's changes."
+
+
+Case 20
+~~~~~~~
+Gary wants to update to receive Henninge's changes, without splitting a library
+out.
+
+ $ bzr split --nested project/library6
+ $ bzr commit project -m "Turned library6 into a library"
+ # i.e. a cherrypick that skips the revision where library6 became a library.
+ $ bzr merge -d project/library6 http://library6 -r 5..-1
+ $ bzr commit project -m "Merge Henninge's changes."
+
+Case 21
+~~~~~~~
+
+John works on a project called FooBar, but has decided that it would be better
+structured as two projects, where Bar is a library that may be of general use
+outside of Foo. As it happens, bar already has its own subdirectory.
+
+He runs:
+::
+
+ # Convert into two trees: foobar and foobar/bar.
+ # In each tree, files will be removed and deleted. In foobar/bar, "bar"
+ # will have been moved to become the tree root.
+ # These changes will be committed later.
+ $ bzr upgrade foobar --format=subbranches
+ $ bzr split foobar/bar
+
+ # Add a tree-reference from foobar to foobar/bar, change bar's branch
+ # to a reference to subbranch in foobar's branch.
+ $ bzr join --nested foobar/bar
+
+ # This recurses into foobar/bar and commits the deletion of the containing
+ # tree. In foobar, it commits a kind change for 'bar' from directory to
+ # tree-reference, and the deletion of the contents of bar.
+ $ bzr commit foobar
+
+This commits new revisions to foobar and bar, and foobar's tree-reference bar
+refers to the revision-id of bar.
+
+Next, he adds two new files: foobar/baz and foobar/bar/qux::
+
+ $ vi foobar/baz
+ $ vi foobar/bar/qux
+ # This adds qux to foobar/bar and adds baz to foobar.
+ $ bzr add foobar
+
+Since foobar/bar/qux is in a commitable state and foobar/baz is not, he invokes
+::
+
+ $ bzr commit foobar/bar
+
+This commits foobar/bar/baz/qux to the subtree and commits foobar/bar to the
+containing tree.
+
+(Had he wanted to commit to just the subtree, or just the containing tree, he
+could have specified an option.)
+
+
+Case 21
+~~~~~~~
+
+Robert wants to hack on a project, Baz, that is structured as a nested tree,
+which uses the library "quxlib", from quxlib.org.
+
+He runs:
+::
+
+ $ bzr branch http://baz.org/dev baz
+
+This creates a "subbranches" branch and working tree for baz, as normal. Since
+tree-references were encountered, it adds subbranches for them to the baz
+branch. All data is retrieved from baz.org, not quxlib.org.
+
+It creates a working tree for quxlib with a subbranch-reference. It uses the
+revision-id from the tree-reference in the containing tree, not the head
+revision at baz.org. This allows Robert to get a known-good nested tree.
+
+Later, Robert decides to update the version of quxlib being used to the latest
+from quxlib.org. He runs::
+
+ $ bzr pull -d http://quxlib.org
+
+This updates the version of quxlib in the working tree, which mean that baz is
+now out-of-date with its last-committed tree. Unfortunately, the new rev on
+quxlib is not completely compatible with the old one, and Robert must tweak a
+few files before Baz runs properly. Once he has done so, he runs::
+
+ $ bzr commit baz
+
+Now he has committed a known-good nested tree, and the baz working tree is once
+again up-to-date.
+
+
+User documentation
+******************
+
+For many large projects, it is often useful to incorporate libraries
+maintained elsewhere or to construct them from multiple subprojects.
+While it is easy for a single user to set up a particular layout of
+multiple branches by hand, the different branches really need to be
+linked together if others are to reproduce the desired layout, and
+if the relationships are going to be managed over time.
+
+Bazaar has good support for building and managing external libraries
+and subprojects via a feature known as *nested trees*. In particular,
+nearly all of Bazaar's commonly used commands understand nested trees
+and Do The Right Thing as explained below. The relationship is hierarchical:
+the containing tree knows about its nested trees, but nested trees are unaware
+of the tree (or trees) containing them.
+
+At the moment, *nested trees* are the only type of nested item
+supported though *nested files* may be supported in the future.
+Nested trees may contain other nested trees as required.
+
+Note: This feature requires a recent branch format such as ``2.0``
+or later.
+
+
+Nesting an external project
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To link an external project into a branch, use the ``branch`` command
+with the ``--nested`` option like this::
+
+ bzr branch --nested SOURCE-URL TARGET-DIR
+
+For example, assuming you already have a ``src/lib`` directory where
+libraries are kept::
+
+ bzr branch --nested http://example.com/xmlsaxlib src/lib/sax
+
+This will create a nested branch in the ``src/lib/sax`` directory,
+join it into the containing branch and save the source location.
+
+If you now run ``bzr status``, it will show the nested branch as
+uncommitted changes like this::
+
+ + src/lib/sax
+ + src/lib/sax/README
+ + src/lib/sax/parser.py
+ ...
+
+To record this change, use the ``commit`` command as you normally would::
+
+ bzr commit -m "added SAX parsing library"
+
+Note that Bazaar stores the tip revision of each nested branch. This
+is an important feature in that it's then easy to reproduce the exact
+combination of libraries used for historical revisions. It also means
+that other developers pulling or merging your changes will get nested
+branches created for them at the right revisions of each.
+
+
+Refreshing a nested branch
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As bugs are fixed and enhancements are made to nested projects, you
+will want to update the version being used. To do this, ``pull`` the
+latest version of the nested branch. For example::
+
+ bzr pull -d src/lib/sax
+
+If the latest revision is too unstable, you can always use the ``-r``
+option on the ``pull`` command to nominate a particular revision or tag.
+
+Now that you have the required version of the code, you can make
+any required adjustments (e.g. API changes), run your automated tests
+and commit something like this::
+
+ view src/lib/sax/README
+ (hack, hack, hack)
+ make test
+ bzr commit -m "upgraded SAX library to version 2.1.3"
+
+
+Changing a nested tree
+~~~~~~~~~~~~~~~~~~~~~~
+
+As well as keeping track of which revisions of external libraries
+are used over time, one of the reasons for nesting projects is to
+make minor changes. You may want to do this in order to fix and
+track particular bugs you need addressed. In other cases, you may want
+to make various local enhancements that aren't valuable outside
+the context of your project.
+
+As support for nested branches is integrated into most commonly
+used commands, this is actually quite easy to do: simply make
+the change to the required files as you normally would! For example::
+
+ edit src/lib/sax/parser.py
+ bzr commit -m "fix bug #42 in sax parser"
+
+Note that Bazaar is smart enough to recurse by default into nested
+branches, commit changes there, and commit the new nested branch tips
+in the current branch. Both commits get the same commit message.
+
+If you want to only commit the change to a nested branch for now, you
+can change into the nested branch before running commit like this::
+
+ cd src/lib/sax
+ bzr commit -m "fix bug #42 in sax parser"
+
+Alternatively, you can use a selective commit like this::
+
+ bzr commit -m "fix bug #42 in sax parser" src/lib/sax
+
+
+Reviewing nested tree changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Just like ``commit``, the ``status`` and ``diff`` commands implicitly
+recurse into nested trees. In the case of ``status``, it shows both the
+nested tree as having a pending change as well as the items within it that have
+changed. For example::
+
+ M src/lib/sax
+ M src/lib/sax/parser.py
+
+Once again, if you change into a nested tree though, ``status`` and
+``diff`` will operate just on that tree and not recurse upwards by
+default.
+
+
+Browsing nested tree history
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As the branches of nested trees have their own history, the ``log`` command
+shows just the history of the containing branch. To see the history for
+a nested branch, nominate the branch explicitly like this::
+
+ bzr log src/lib/sax
+
+Note however that ``log -v`` and ``log -p`` on the containing branch
+will show what files in nested branches were changed in each revision.
+
+
+Splitting out a project
+~~~~~~~~~~~~~~~~~~~~~~~
+
+If you already have a large project and wish to partition it into
+reusable subprojects, use the ``split`` command. This takes an existing
+directory and makes it a separate branch. For example, imagine you have
+a directory holding UI widgets that another project would like to
+leverage. You can make it a separate branch like this::
+
+ bzr split src/uiwidgets
+
+To make the new project available to others, push it to a shared location
+like this::
+
+ cd src/uiwidgets
+ bzr push bzr://example.com/uiwidgets
+
+You also need to link it back into the original project as a nested branch
+using the ``join`` command like this (assuming the current directory is
+``src/uiwidgets``)::
+
+ bzr join --nested .
+ bzr commit -m "uiwidgets is now a nested project"
+
+Similar to ``branch --nested``, ``join --nested`` joins the nominated directory
+(which must hold a branch) into the containing tree. In order to make sure
+that all versions of a tree can be reproduced, the branches of nested trees
+share a repository with their containing tree.
+
+
+Virtual projects
+~~~~~~~~~~~~~~~~
+
+By design, Bazaar is strict about tracking the actual revisions used of
+nested branches over time. Without this, projects cannot accurately
+reproduce exactly what was used to make a given build. There are
+isolated use cases though where is advantageous to say "give me the
+latest tip of these loosely coupled branches". To do this, create a
+small 'virtual project' which is just a bunch of *unpegged* nested
+branches. To mark nested branches as unpegged, use the ``--no-pegged``
+option of the ``join`` command like this::
+
+ bzr join --nested --no-pegged [DIR]
+
+To stop the nested branch tips from floating and to begin recording
+the tip revisions again, use the ``pegged`` option::
+
+ bzr join --nested --pegged [DIR]
+
+After changing whether one or more nested branches are pegged or not, you
+need to ``commit`` the branch to record that metadata. (The pegged state
+is recorded over time.)
+
+For example, you may be managing a company intranet site as a project
+which is nothing more than a list of unrelated departmental websites
+bundled together. You can set this up like this::
+
+ bzr init intranet-site
+ cd intranet-site
+ bzr branch bzr://ourserver/websites/research
+ bzr branch bzr://ourserver/websites/development
+ bzr branch bzr://ourserver/websites/support
+ bzr branch bzr://ourserver/websites/hr
+ bzr join --nested --no-pegged research
+ bzr join --nested --no-pegged development
+ bzr join --nested --no-pegged support
+ bzr join --nested --no-pegged hr
+ bzr commit -m "initial configuration of intranet-site"
+
+Publishing the overall site is then as easy as going to the server
+hosting your intranet and running something like::
+
+ bzr branch http://mymachine//projects/intranet-site
+
+Refreshing the overall site is as easy as::
+
+ bzr pull
+
+Virtual projects are also useful for providing a partial 'view' over
+a large project containing a large number of subprojects. For example,
+you may be working on an office suite and have a bunch of developers
+that only care about the word processor. You can create a virtual
+project for them like this::
+
+ bzr init wp-modules
+ cd wp-modules
+ bzr branch ../common
+ bzr branch ../printing
+ bzr branch ../spellchecker
+ bzr branch ../wordprocessor
+ bzr join --nested --no-pegged common
+ bzr join --nested --no-pegged printing
+ bzr join --nested --no-pegged spellchecker
+ bzr join --nested --no-pegged wordprocessor
+ bzr commit -m "initial configuration of wp-modules"
+
+Those developers can then get bootstrapped faster and have *just* the
+subprojects they care about by branching from ``wp-modules``.
+
+
+Nested branch tips & tricks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As explained above, most of Bazaar's commonly used commands recurse
+downwards into nested branches by default. To prevent this recursion,
+use the ``--no-recurse-nested`` option on various commands (including
+``commit``, ``status`` and ``diff``) that support it.
+
+Thanks to plugins like bzr-svn and bzr-git, Bazaar has strong support
+for transparently accessing branches managed by foreign VCS tools. This
+means that Bazaar can support projects where nested branches are hosted
+in supported foreign systems. For example, to nest a library maintained
+in Subversion::
+
+ bzr branch --nested svn://example.com/xmlhelpers src/lib/xmlhelpers
+
+If you want revisions to be committed both to a remote location and a
+local location, make the top-level branch a bound branch. (Nested branches
+have no configuration of their own.)
+
+Most likely, you will have some branches that are identical to their upstream
+version and can be pulled, and some that have local changes and must be merged.
+You can update all of them at once using ``merge --pull``. This will pull
+into the trees with no local changes, and merge into the ones with local
+changes. Afterward, you should commit, which will commit only into the
+trees that were merged into.
+
+As you'd expect, a nested branch can be moved or deleted using the
+normal commands. For example, after splitting out a subproject, you
+may want to change its location like this::
+
+ bzr mv src/uiwidgets src/lib/uiwidgets
+ bzr commit -m "move uiwidgets into src/lib"
+
+Things to be aware of
+~~~~~~~~~~~~~~~~~~~~~
+
+Commands like ``commit`` and ``push`` need online access to the locations
+for nested branches which have updated their tip. In particular, ``commit``
+will update any changed nested branches first and only commit to the
+containing branch if all nested branch commits succeed. If you are working
+offline, you may want to ensure you have a local mirror location defined
+for nested branches you are likely to tweak. Alternatively, the
+``no-recurse-nested`` option to the ``commit`` command might to useful to
+commit some changes, leaving the nested branch commits until you are back
+online.
+
+At the moment, nested trees need to be incorporated as a whole.
+Filtered views can be used to restrict the set of files and directories
+logically seen. Currently though, filtered views are a lens onto a tree:
+they do not delete other files and the exposed files/directories must
+have the same paths as they do in the original branch. In the future,
+we may add support for nesting and moving selected files from a
+(read-only) nested branch something like this::
+
+ bzr nested DIR --file LICENSE --file doc/README::README
+ bzr commit -m "change which files are nested from project DIR"
+
+If you require this feature, please contact us with your needs.
+
+Design decisions
+****************
+
+The branches of subtrees shall either share a repository with the containing tree,
+or the containing tree's repository will be (implicitly) added as a fallback
+repository.
+
+The branches of subtrees shall be in a special format that shares a single
+last_revision file that is stored in the containing branch.
+
+The subtree branches shall be referenced in the last_revision file by file-id.
+
+Subtree branches shall not support individual configuration.
+
+Fetch shall automatically fetch the revisions mentioned by tree-references,
+recursively.
+
+The reserved revision-id "head:" shall be used in tree-references to refer to
+the tip revision of a branch.
+
+bzr-svn repositories with externals shall behave as though the multiple
+repositories were a single Bazaar repository with multiple branches.
+
+Shall commands recurse downwards by default?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Yes.
+
+Pros:
+
+ - It is hard to accidentally produce inconsistent trees
+ - Inconsistent trees are hard for remote users to handle
+ - Accidentally committing too many things at once is easy to resolve
+ - It is hard to accidentally commit too many things at once
+
+Cons:
+
+ - Accidentally committing nuclear launch codes is easier to do
+ - A commit message that makes sense for the top may not make sense lower down.
+
+
+Shall commands recurse upwards by default?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+No.
+
+
+Shall subtree branches be addressable?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Ideally, yes. We might want to use the path segment parameters syntax here too.
+
+
+Shall we model nested trees as a composite tree?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Yes. Users will see recurse-downwards behaviour that allows operations that
+cross subtree boundaries, e.g. a merge in the top tree can move a file between
+subtrees.
+
+The downside is that we can't have cheap support for subtrees that are copies
+of one another, because we wouldn't know which copy to apply sets of changes
+to.
+
+
+Shall we use root-ids for tree references?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Yes. This fits well with our current lack of support of file copies. If we do
+support file copies in future it will be possible to change this in a future
+format, and perform deterministic upgrades to that format.
+
+
+What about locking?
+~~~~~~~~~~~~~~~~~~~
+
+We should lock recursively. It matches existing behaviour by failing earlier,
+and the extra cost does not seem onerous. (To be fully efficient this requires
+an index of the subtrees, otherwise we need to scan the fully
+inventory/dirstate.)
+
+(Also, this decision can be changed later with no compatibility concerns.)
+
+
+How do we handle merge when the subtree hasn't diverged?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+"bzr merge --pull" will be changed so that it will merge (not pull) when the
+local last revision's revno would change (i.e. is a non-lhs parent in the merge
+source). This is expected to be the most common way to update nested trees.
+
+The existing "bzr merge --pull" behaviour will be renamed to "bzr merge
+--pull-renumber".
+
+"bzr merge" (with no "--pull") will do a merge in all trees. "bzr pull" will
+do a pull in all trees.
+
+The rationale is that a very common use-case is that the top tree is a project
+the user is actively committing to, and the subtrees are mainly libraries that
+are being mirrored. So a behaviour that forced every update to be a merge
+would be undesirable for the mirrored subtrees, but an update that is a pull
+wouldn't suit the changing top tree. And the existing "merge --pull" (that can
+renumber revisions) isn't desireable for either the top tree or subtrees in
+this case.
+
+
+What should uncommit do?
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+It will recurse, and subtrees will be uncommitted back to the revision recorded
+by the revision the top tree is uncommitting to.
+
+This means that operations like::
+
+ $ echo foo > versioned-file-in-top-tree.txt
+ $ bzr ci -m "Change file"
+ $ bzr uncommit
+
+will not cause a change in subtrees, since the top-level commit did not affect
+them. But on the other hand:
+
+ $ echo foo > subtree/versioned-file-in-subtree.txt
+ $ bzr ci -m "Change file"
+ $ bzr uncommit
+
+will first uncommit to the subtree, then to the top tree. The uncommit will
+restore both trees to their previous state.
+
+
+Some subtrees should have commits and some should not. How?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We will not provide special support for this initially. We might later support
+flagging some sub-trees as mirror-only or something similar, but this seems like
+it could be a general feature not specific to nesting. (and it may only require
+a working tree format bump to add).
+
+Comparison with other systems
+*****************************
+
+Git submodules
+~~~~~~~~~~~~~~
+
+This allows separate repositories to be used for submodules.
+
+Mercurial Forests
+~~~~~~~~~~~~~~~~~
+
+The wiki page does not give confidence that this is a well-maintained project.
+It seems similar to config-manager-- its 'snapshot' files are like
+config-manager's config files, describing what branches to get and where to put
+them, optionally specifying a revision. No metadata about nesting is stored in
+the tree. Optionally, a 'snapshot.txt' file may be stored in the containing
+tree, but it can also be stored somewhere else.
+
+There is no attempt to integrate subtree support into the core commands.
+
+Mercurial Nested Repositories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This design was for an integrated feature, but there are apparently 4
+implementations as extensions. While it does integrate subtree support into
+core commands, this may be off by default: "The alternative that I lean towards
+is to not recurse unless explicitly instructed to. Most probably, only a few
+commands should arguably even be aware of modules."
+
+Command comparison:
+
+- hg module add ~= bzr join --nested
+- hg module remove ~= bzr remove --keep
+- hg module record's functionality is part of nested commits in nested trees.
+
+Like submodules, this stores location information in versioned data: a
+.hgmodules directory.
+Like submodules and nested trees, particular revisions are recorded.
+
+Subversion "svn:externals"
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+Like bzr, uses per-file metadata. Like submodules and nested repositories,
+locations are versioned data. Like Forests, revisions are optional. Like
+nested repositories, there is limited integration into core commands; checkout
+and update support externals, and commit may support them in the future.
+However, there is no UI specific to creating and updating svn:externals
+references.
+
+Unlike all other alternatives, supports partial checkouts. This is because svn
+natively supports partial checkouts. Also, supports checkouts of tags, because
+tags are merely a convention in svn.
+
+Supports pulling in "head" subtrees too, not just specific ("known-good")
+revisions. Nested trees supports this in order to provide high-fidelity
+imports.
+
+Some support for single-file svn:externals (see
+http://subversion.tigris.org/svn_1.6_releasenotes.html#externals), whereas bzr
+subtrees must be directories.
+
+Has a --ignore-externals option for checking out without pulling in the
+svn:externals items (svn checkout is more or less equivalent to bzr branch).
+You can also use that option on update (more or less like bzr merge).
+
+
+Comments on differences
+~~~~~~~~~~~~~~~~~~~~~~~
+externals support partial checkouts. Nested trees could gain support for this
+once Bazaar itself supports partial checkouts. Supporting a single file as a
+"subtree" would also depend on native bzr support. On platforms that support
+symlinks, using symlinks to portions of a subtree can be an effective
+substitute.
+
+.. vim: ft=rst
diff --git a/doc/developers/network-protocol.txt b/doc/developers/network-protocol.txt
new file mode 100644
index 0000000..bc6aab6
--- /dev/null
+++ b/doc/developers/network-protocol.txt
@@ -0,0 +1,468 @@
+================
+Network Protocol
+================
+
+:Date: 2009-01-07
+
+
+.. contents::
+
+
+Overview
+========
+
+The smart protocol provides a way to send requests and corresponding
+responses to communicate with a remote bzr process.
+
+Layering
+========
+
+Medium
+------
+
+At the bottom level there is either a socket, pipes, or an HTTP
+request/response. We call this layer the *medium*. It is responsible for
+carrying bytes between a client and server. For sockets, we have the idea
+that you have multiple requests and get a read error because the other
+side did shutdown. For pipes we have read pipe which will have a zero
+read which marks end-of-file. For HTTP server environment there is no
+end-of-stream because each request coming into the server is independent.
+
+So we need a wrapper around pipes and sockets to separate out requests
+from substrate and this will give us a single model which is consistent
+for HTTP, sockets and pipes.
+
+Protocol
+--------
+
+On top of the medium is the *protocol*. This is the layer that
+deserialises bytes into the structured data that requests and responses
+consist of.
+
+Request/Response processing
+---------------------------
+
+On top of the protocol is the logic for processing requests (on the
+server) or responses (on the client).
+
+Server-side
+-----------
+
+Sketch::
+
+ MEDIUM (factory for protocol, reads bytes & pushes to protocol,
+ uses protocol to detect end-of-request, sends written
+ bytes to client) e.g. socket, pipe, HTTP request handler.
+ ^
+ | bytes.
+ v
+
+ PROTOCOL(serialization, deserialization) accepts bytes for one
+ request, decodes according to internal state, pushes
+ structured data to handler. accepts structured data from
+ handler and encodes and writes to the medium. factory for
+ handler.
+ ^
+ | structured data
+ v
+
+ HANDLER (domain logic) accepts structured data, operates state
+ machine until the request can be satisfied,
+ sends structured data to the protocol.
+
+Request handlers are registered in the `bzrlib.smart.request` module.
+
+
+Client-side
+-----------
+
+Sketch::
+
+ CLIENT domain logic, accepts domain requests, generated structured
+ data, reads structured data from responses and turns into
+ domain data. Sends structured data to the protocol.
+ Operates state machines until the request can be delivered
+ (e.g. reading from a bundle generated in bzrlib to deliver a
+ complete request).
+
+ This is RemoteBzrDir, RemoteRepository, etc.
+ ^
+ | structured data
+ v
+
+ PROTOCOL (serialization, deserialization) accepts structured data for one
+ request, encodes and writes to the medium. Reads bytes from the
+ medium, decodes and allows the client to read structured data.
+ ^
+ | bytes.
+ v
+
+ MEDIUM accepts bytes from the protocol & delivers to the remote server.
+ Allows the protocol to read bytes e.g. socket, pipe, HTTP request.
+
+The domain logic is in `bzrlib.remote`: `RemoteBzrDir`, `RemoteBranch`,
+and so on.
+
+There is also a plain file-level transport that calls remote methods to
+manipulate files on the server in `bzrlib.transport.remote`.
+
+Protocol description
+====================
+
+Version one
+-----------
+
+Version one of the protocol was introduced in Bazaar 0.11.
+
+The protocol (for both requests and responses) is described by::
+
+ REQUEST := MESSAGE_V1
+ RESPONSE := MESSAGE_V1
+ MESSAGE_V1 := ARGS [BODY]
+
+ ARGS := ARG [MORE_ARGS] NEWLINE
+ MORE_ARGS := SEP ARG [MORE_ARGS]
+ SEP := 0x01
+
+ BODY := LENGTH NEWLINE BODY_BYTES TRAILER
+ LENGTH := decimal integer
+ TRAILER := "done" NEWLINE
+
+That is, a tuple of arguments separated by Ctrl-A and terminated with a
+newline, followed by length prefixed body with a constant trailer. Note
+that although arguments are not 8-bit safe (they cannot include 0x01 or
+0x0a bytes without breaking the protocol encoding), the body is.
+
+Version two
+-----------
+
+Version two was introduced in Bazaar 0.16.
+
+The request protocol is::
+
+ REQUEST_V2 := "bzr request 2" NEWLINE MESSAGE_V2
+
+The response protocol is::
+
+ RESPONSE_V2 := "bzr response 2" NEWLINE RESPONSE_STATUS NEWLINE MESSAGE_V2
+ RESPONSE_STATUS := "success" | "failed"
+
+Future versions should follow this structure, like version two does::
+
+ FUTURE_MESSAGE := VERSION_STRING NEWLINE REST_OF_MESSAGE
+
+This is so that clients and servers can read bytes up to the first newline
+byte to determine what version a message is.
+
+For compatibility will all versions (past and future) of bzr clients,
+servers that receive a request in an unknown protocol version should
+respond with a single-line error terminated with 0x0a (NEWLINE), rather
+than structured response prefixed with a version string.
+
+Version two of the message protocol is::
+
+ MESSAGE_V2 := ARGS [BODY_V2]
+ BODY_V2 := BODY | STREAMED_BODY
+
+That is, a version one length-prefixed body, or a version two streamed
+body.
+
+Version two with streamed bodies
+--------------------------------
+
+An extension to version two allows streamed bodies. A streamed body looks
+a lot like HTTP's chunked encoding::
+
+ STREAMED_BODY := "chunked" NEWLINE CHUNKS TERMINATOR
+ CHUNKS := CHUNK [CHUNKS]
+ CHUNK := HEX_LENGTH CHUNK_CONTENT
+ HEX_LENGTH := HEX_DIGITS NEWLINE
+ CHUNK_CONTENT := bytes
+
+ TERMINATOR := SUCCESS_TERMINATOR | ERROR_TERMINATOR
+ SUCCESS_TERMINATOR := 'END' NEWLINE
+ ERROR_TERMINATOR := 'ERR' NEWLINE CHUNKS SUCCESS_TERMINATOR
+
+That is, the body consists of a series of chunks. Each chunk starts with
+a length prefix in hexadecimal digits, followed by an ASCII newline byte.
+The end of the body is signaled by '``END\\n``', or by '``ERR\\n``'
+followed by error args, one per chunk. Note that these args are 8-bit
+safe, unlike request args.
+
+A streamed body starts with the string "chunked" so that legacy clients
+and servers will not mistake the first chunk as the start of a version one
+body.
+
+The type of body (length-prefixed or chunked) in a response is always the
+same for a given request method. Only new request methods introduced in
+Bazaar 0.91 and later use streamed bodies.
+
+Version three
+-------------
+
+.. note::
+
+ For some discussion of the requirements that led to this new protocol
+ version, see `bug #83935`_.
+
+.. _bug #83935: https://bugs.launchpad.net/bzr/+bug/83935
+
+Version three has bencoding of most protocol structures, to make parsing
+simpler. For extra parsing convenience, these structures are length
+prefixed::
+
+ LENGTH_PREFIX := 32-bit unsigned integer in network byte order
+
+Unlike earlier versions, clients and servers are no longer required to
+know which request verbs and responses will have bodies attached. Because
+of length-prefixing and other changes, it is always possible to know when
+a complete request or response has been read, even if the server
+implements no verbs.
+
+The underlying message format is::
+
+ MESSAGE := MAGIC NEWLINE HEADERS CONTENTS END_MESSAGE
+ MAGIC := "bzr message 3 (bzr 1.6)"
+ HEADERS := LENGTH_PREFIX bencoded_dict
+ END_MESSAGE := "e"
+
+ BODY := MESSAGE_PART+
+ MESSAGE_PART := ONE_BYTE | STRUCTURE | BYTES
+ ONE_BYTE := "o" byte
+ STRUCTURE := "s" LENGTH_PREFIX bencoded_structure
+ BYTES := "b" LENGTH_PREFIX bytes
+
+(Where ``+`` indicates one or more.)
+
+This format allows an arbitrary sequence of message parts to be encoded
+in a single message. The contents of a MESSAGE have a higher-level
+message, but knowing just this amount of data it's possible to
+deserialize and consume a message, so that implementations can respond to
+messages sent by later versions.
+
+Headers
+~~~~~~~
+
+Each request and response will have “headers”, a dictionary of key-value pairs.
+The keys must be strings, not any other type of value.
+
+Currently, the only defined header is “Software version”. Both the client and
+the server should include a “Software version” header, with a value of a
+free-form string such as “bzrlib 1.5”, to aid debugging and logging. Clients
+and servers **should not** vary behaviour based on this string.
+
+Conventional requests and responses
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By convention, most requests and responses have a simple “arguments plus
+optional body” structure, as in earlier protocol versions. This section
+describes how such messages are encoded. All requests and responses
+defined by earlier protocol versions must be encoded in this way.
+
+Conventional requests will send a CONTENTS of ::
+
+ CONV_REQ := ARGS SINGLE_OR_STREAMED_BODY?
+ SINGLE_OR_STREAMED_BODY := BYTES
+ | BYTES+ TRAILER
+
+ ARGS := STRUCTURE(argument_tuple)
+ TRAILER := SUCCESS_STATUS | ERROR
+ SUCCESS_STATUS := ONE_BYTE("S")
+ ERROR := ONE_BYTE("E") STRUCTURE(argument_tuple)
+
+Conventional responses will send CONTENTS of ::
+
+ CONV_RESP := RESP_STATUS ARGS SINGLE_OR_STREAMED_BODY?
+ RESP_STATUS := ONE_BYTE("S") | ONE_BYTE("E")
+
+If the RESP_STATUS is success ("S"), the arguments are the
+method-dependent result.
+
+For errors (where the Status byte of a response or a streamed body is
+"E"), the situation is analagous to requests. The first item in the
+encoded sequence must be a string of the error name. The other arguments
+supply details about the error, and their number and types will depend on
+the type of error (as identified by the error name).
+
+Note that the streamed body from version two is now just multiple
+BYTES parts.
+
+The end of the request or response is indicated by the lower-level
+END_MESSAGE. If there's only one BYTES element in the body, the TRAILER
+may or may not be present, depending on whether it was sent as a single
+chunk or as a stream that happens to have one element.
+
+ *(Discussion)* The success marker at the end of a streamed body seems
+ redundant; it doesn't have space for any arguments, and the end of the
+ body is marked anyhow by the end of the message. Recipients shouldn't
+ take any action on it, though they should map an error into raising an
+ error locally.
+
+ 1.10 clients don't assert that they get a status byte at the end of the
+ message. They will complain (in
+ ``ConventionalResponseHandler.byte_part_received``) if they get an
+ initial success and then another byte part with no intervening bytes.
+ If we stop sending the final success message and only flag errors
+ they'll only get one if the error is detected after streaming starts but
+ before any bytes are actually sent. Possibly we should wait until at
+ least the first chunk is ready before declaring success.
+
+For new methods, these sequences are just a convention and may be varied
+if appropriate for a particular request or response. However, each
+request should at least start with a STRUCTURE encoding the arguments
+tuple. The first element of that tuple must be a string that names the
+request method. (Note that arguments in this protocol version are
+bencoded. As a result, unlike previous protocol versions, arguments in
+this version are 8-bit clean.)
+
+ (Discussion) We're discussing having the byte segments be not just a
+ method for sending a stream across the network, but actually having them
+ be preserved in the RPC from end to end. This may be useful when
+ there's an iterator on one side feeding in to an iterator on the other,
+ if it avoids doing chunking and byte-counting at two levels, and if
+ those iterators are a natural place to get good granularity. Also, for
+ cases like ``insert_record_stream`` the server can't do much with the
+ data until it gets a whole chunk, and so it'll be natural and efficient
+ for it to be called with one chunk at a time.
+
+ On the other hand, there may be times when we've got some bytes from the
+ network but not a full chunk, and it might be worthwhile to pass it up.
+ If we promise to preserve chunks, then to do this we'd need two separate
+ streaming interfaces: "we got a chunk" and "we got some bytes but not
+ yet a full chunk". For ``insert_record_stream`` the second might not be
+ useful, but it might be good when writing to a file where any number of
+ bytes can be processed.
+
+ If we promise to preserve chunks, it'll tend to make some RPCs work only
+ in chunks, and others just on whole blocks, and we can't so easily
+ migrate RPCs from one to the other transparently to older
+ implementations.
+
+ The data inside those chunks will be serialized anyhow, and possibly the
+ data inside them will already be able to be serialized apart without
+ understanding the chunks. Also, we might want to use these formats e.g.
+ for pack files or in bundles, and so they don't particularly need
+ lower-level chunking. So the current (unmerged, unstable) record stream
+ serialization turns each record into a bencoded tuple and it'd be
+ feasible to parse one tuple at a time from a byte stream that contains a
+ sequence of them.
+
+ So we've decided that the chunks won't be semantic, and code should not
+ count on them being preserved from client to server.
+
+Early error returns
+~~~~~~~~~~~~~~~~~~~
+
+ *(Discussion)* It would be nice if the server could notify the client of
+ errors even before a streaming request has finished. This could cover
+ situtaions such as the server not understanding the request, it being
+ unable to open the requested location, or it finding that some of the
+ revisions being sent are not actually needed.
+
+ Especially in the last case, we'd like to be able to gracefully notice
+ the condition while the client is writing, and then have it adapt its
+ behaviour. In any case, we don't want to have drop and restart the
+ network stream.
+
+ It should be possible for the client to finish its current chunk and
+ then its message, possibly with an error to cancel what's already been
+ sent.
+
+ This relies on the client being able to read back from the server while
+ it's writing. This is technically difficult for HTTP but feasible over
+ a socket or SSH.
+
+ We'd need a clean way to pass this back to the request method, even
+ though it's presumably in the middle of doing its body iterator.
+ Possibly the body iterator could be manually given a reference to the
+ request object, and it can poll it to see if there's a response.
+
+ Perhaps we need to distinguish error conditions, which should turn into
+ a client-side error regardless of the request code, from early success,
+ which should be handled only if the request code specifically wants to
+ do it.
+
+Full-duplex operation
+~~~~~~~~~~~~~~~~~~~~~
+
+ Code not geared to do pipelined requests, and this might require doing
+ asynchrony within bzrlib. We might want to either go fully pipelined
+ and asynchronous, but there might be a profitable middle ground.
+
+ The particular case where duplex communication would be good is in
+ working towards the common points in the graphs between the client and
+ server: we want to send speculatively, but detect as soon as they've
+ matched up.
+
+ So we could for instance have a synchronous core, but rely on the OS
+ network buffering to allow us to work on batches of say 64kB. We can
+ also pipeline requests and responses, without allowing for them
+ happening out of order, or mixed requests happening at the same time.
+
+ Wonder how our network performance would have turned out now if we'd
+ done full-duplex from the start, and ignored hpss over HTTP. We have
+ pretty good (read-only) HTTP support just over dumb HTTP, and that may be
+ better for many users.
+
+
+
+APIs
+====
+
+On the client, the bzrlib code is "in charge": when it makes a request, or
+asks from data from the network, that causes network IO. The server is
+event driven: the network code tells the response handler when data has
+been received, and it takes back a Response object from the request
+handler that is then polled for body stream data.
+
+Paths
+=====
+
+Paths are passed across the network. The client needs to see a namespace
+that includes any repository that might need to be referenced, and the
+client needs to know about a root directory beyond which it cannot ascend.
+
+Servers run over SSH will typically want to be able to access any path the
+user can access. Public servers on the other hand (which might be over
+HTTP, SSH or TCP) will typically want to restrict access to only a
+particular directory and its children, so will want to do a software
+virtual root at that level. In other words they'll want to rewrite
+incoming paths to be under that level (and prevent escaping using ../
+tricks). The default implementation in bzrlib does this using the
+`bzrlib.transport.chroot` module.
+
+URLs that include ~ are passed across to the server verbatim and the
+server can expand them. The default implementation in bzrlib does this
+using `bzrlib.transport.pathfilter` and `os.path.expanduser`, taking care
+to respect the virtual root.
+
+Paths in request arguments are UTF-8 encoded, except for the legacy VFS
+requests which expect escaped (`bzrlib.urlutils.escape`) paths.
+
+
+Requests
+========
+
+The first argument of a request specifies the request method.
+
+The available request methods are registered in `bzrlib.smart.request`.
+
+**XXX**: ideally the request methods should be documented here.
+Contributions welcome!
+
+
+Recognised errors
+=================
+
+The first argument of an error response specifies the error type.
+
+One possible error name is ``UnknownMethod``, which means the server does
+not recognise the verb used by the client's request. This error was
+introduced in version three.
+
+**XXX**: ideally the error types should be documented here. Contributions
+welcome!
+
+..
+ vim: ft=rst tw=74 ai
+
diff --git a/doc/developers/new-config-rationale.txt b/doc/developers/new-config-rationale.txt
new file mode 100644
index 0000000..f4e2173
--- /dev/null
+++ b/doc/developers/new-config-rationale.txt
@@ -0,0 +1,790 @@
+================================
+Simplifying Bazaar Configuration
+================================
+
+Goal
+====
+
+Not all needs can be addressed by the default values used inside bzr and
+bzrlib, no matter how well they are chosen (and they are ;).
+
+Options that are rarely used don't deserve a corresponding command line
+switch in one or several commands.
+
+Many parts of ``bzrlib`` depends on some constants though and the user
+should be able to customize the behavior to suit his needs so these
+constants need to become configuration options or more generally, be easier
+to set.
+
+These options can be set from the command-line, acquired from an environment
+variable or recorded in a configuration file.
+
+To simplify writing (and reading), this document refers to the old and new
+config designs:
+* the old design is using ``Config`` as a base class for all config files,
+* the new design use ``ConfigStacks`` of ``Section`` from config ``Stores``.
+
+
+Current issues
+==============
+
+* Many parts of ``bzrlib`` declare constants and there is no way for the
+ user to look at or modify them (see http://pad.lv/832061).
+
+* The old design requires a configuration object to create, modify or delete
+ a configuration option in a given configuration file. ``bzr config``
+ makes it almost transparent for the user. Internally though, not all cases
+ are handled: only BranchConfig implements chained configs, nothing is
+ provided at the repository level and too many plugins define their own
+ section or even their own config file. (config.Stack now provides a way to
+ chain config files, BranchStack properly implements the desired behavior,
+ ``bzr config`` uses the new design).
+
+* ``locations.conf`` defines the options that need to override any setting
+ in ``branch.conf`` for both local and remotes branches (but some remote
+ branch options just ignore ``locations.conf``). Many users want a way to
+ define default values for options that are not defined in ``branch.conf``
+ (and even more users think that ``locations.conf`` provide default values,
+ see also http://pad.lv/843211 and http://pad.lv/832046). This could be
+ approximated today by *not* defining these options in ``branch.conf`` but
+ in ``locations.conf`` instead. This workaround doesn't allow a user to
+ define defaults in ``locations.conf`` and override them in
+ ``branch.conf``. (Allowing sections in 'bazaar.conf' (or introducing a new
+ defaults.conf' allowing sections) can now address that. Defining and using
+ a new file is easier as it avoids handling a migration path for
+ bazaar.conf and doesn't require banning the use of sections for special
+ purpose needs (ALIASES and BOOKMARKS for example)).
+
+* Defining a new option requires adding a new method in the ``Config``
+ object to get access to features like:
+
+ * should the option be inherited by more specific sections, (this was more
+ or less the default in the old design, it is addressed by section
+ matchers in the new one by letting users define options in whatever
+ relevant section and let the matcher select the right ones).
+
+ * should the inherited value append the relative path between the section
+ one and the location it applies to (see http://pad.lv/832013, fixed),
+
+ * the default value (including calling any python code that may be
+ required to calculate this value)(see http://pad.lv/832064, fixed),
+
+ * priority between sections in various config files (this is defined by
+ the section matcher associated with a given config store for stacks,
+ http://pad.lv/832046 is about adding a section matcher with clearer
+ semantics than the one used for locations.conf).
+
+ A related problem is that, in the actual implementation, some
+ configuration options have defined methods, others don't and this is
+ inconsistent. (Using only Stacks addresses that).
+
+* Access to the 'active' configuration option value from the command line
+ doesn't give access to the specific section. This is a concern if the user
+ has no other way to address a specific configuration option including
+ Store and Section when using ``bzr config`` (see
+ http://pad.lv/725234). Plugins defining their own stacks and/or stores
+ also have no way to properly plug into ``bzr config`` (see
+ http://pad.lv/788991).
+
+* Rules for configuration options are not clearly defined for remote
+ branches (they may differ between dumb and smart servers the former will
+ use the local ``bazaar.conf`` and ``locations.conf`` files while the later
+ will use (or ignore ?) the remote ones).
+
+* The features offered by the Bazaar configuration files should be easily
+ accessible to plugin authors either by supporting plugin configuration
+ options in the configuration files or allowing the plugins to define their
+ own configuration files. (Separating Section, Store and Stack starts
+ addressing that, a stack registry should complete the needed means
+ http://pad.lv/832036).
+
+* While the actual configuration files support sections, they are used in
+ mutually exclusive ways that make it impossible to offer the same set of
+ features to all configuration files:
+
+ * ``bazaar.conf`` use arbitrary names for sections. ``DEFAULT`` is used
+ for global options, ``ALIASES`` are used to define command aliases,
+ plugins can define their own sections, some plugins do that
+ (``bzr-bookmarks`` use ``BOOKMARKS`` for example), some other define
+ their own sections (this is addressed with the new design by using only
+ the ``DEFAULT`` section and ignore the others. When needed, one can
+ create a specific stack to get access to a specific section).
+
+ * ``locations.conf`` use globs as section names. This provides an easy
+ way to associate a set of options to a matching working tree or
+ branch, including remote ones.
+
+ * ``branch.conf`` doesn't use any section.
+
+ This is addressed by defining different stacks selecting the relevant
+ sections from the stores involved. ``ALIASES`` for example can define a
+ stack that select only the ``ALIASES`` section from ``bazaar.conf``.
+
+* There is no easy way to get configuration options for a given repository
+ or an arbitrary path. Working trees and branches are generally organized
+ in hierarchies and being able to share the option definitions is an often
+ required feature. This can also address some needs exhibited by various
+ branch schemes like looms, pipeline, colocated branches and nested
+ trees. Being able to specify options *in* a working tree could also help
+ support conflict resolution options for a given file, directory or
+ subtree (see http://pad.lv/359320).
+
+* Since sections allow different definitions for the same option (in the
+ same store), a total order should be defined between sections to select
+ the right definition for a given context (paths or globs for
+ ``locations.conf`` but other schemes can be used, window names for qbzr,
+ repository UUIDs for bzr-svn for example). Allowing globs for section
+ names is harmful in this respect since the order is currently defined as
+ being based on the number of path components. The caveat here is that if
+ the order is always defined for a given set of sections it can change when
+ one or several globs are modified and the user may get surprising and
+ unwanted results in these cases. The lexicographical order is otherwise
+ fine to define what section is more specific than another. (This may not
+ be a problem in real life since longer globs are generally more specific
+ than shorter ones and explicit paths should also be longer than matching
+ globs. That may leave a glob and a path of equal length in a gray area but
+ in practice using ``bzr config`` should give enough feedback to address
+ them. See also http://pad.lv/832046 asking for a less magical section
+ matcher).
+
+* Internally, configuration files (and their fallbacks, ``bazaar.conf`` and
+ ``locations.conf`` for ``branch.conf``) are read every time *one* option is
+ queried. Likewise, setting or deleting a configuration option implies
+ writing the configuration file *immediately* after re-reading the file to
+ avoid racing updates (see http://pad.lv/832042).
+
+* The current implementation use a mix of transport-based and direct file
+ systems operations (Addressed by Store implementation relying on
+ transports only and the hpss implementing the corresponding verbs).
+
+* While the underlying ``ConfigObj`` implementation provides an
+ interpolation feature, the ``bzrlib`` implementation doesn't provide an
+ easy handling of templates where other configuration options can be
+ interpolated. Instead, ``locations.conf`` (and only it) allows for
+ ``appendpath`` and ``norecurse``. (Cross-section, cross-file interpolation
+ and section local options are now implemented in the new design).
+
+* Inherited list values can't be modified, a more specific configuration can
+ only redefine the whole list.
+
+* There is no easy way to define dicts (the most obvious one being to use a
+ dedicated section which is already overloaded). Using embedded sections
+ for this would not be practical either if we keep using a no-name section
+ for default values. In a few known cases, a bencoded dict is stored in a
+ config value, so while this isn't user-friendly, not providing a better
+ alternative shouldn't be a concern. A possible, limited, implementation
+ can be envisioned: limiting the dict to a single level only, with simple
+ names as keys and unicode strings as values. The keys can then be mapped
+ to options prefixed with the dict name.
+
+
+Proposed implementation
+=======================
+
+
+Configuration files definition
+------------------------------
+
+While of course configurations files can be versioned they are not intended
+to be accessed in sync with the files they refer to (one can imagine
+handling versioned properties this way but this is *not* what the bazaar
+configuration files are targeted at). ``bzr`` will always refer to
+configuration files as they exist on disk when an option is queried or set.
+
+The configuration files are generally local to the file system but some of
+them can be accessed remotely (``branch.conf``, ``repo.conf``).
+
+
+Naming
+------
+
+Option names are organized into a name space for a given stack. One such set
+includes ``bazaar.conf``, ``locations.conf``, ``branch.conf``, etc. Plugins
+can define their own sets for their own needs. While it is conceivable that
+the same option name can be used in unrelated configuration stacks, it seems
+better to define a single name space for all options if only to avoid
+ambiguities.
+
+Using a name space is meant to help:
+
+* avoid collisions between bzr and plugins and between plugins,
+
+* discover the available options and making them easier to remember,
+
+* organise the documentation for the option set.
+
+Using valid python identifiers is recommended but not enforced (but we may
+do so in the future).
+
+The option name space is organized by topic:
+
+* bzrlib options are grouped by topic (``branch``, ``tree``, ``repo``)
+
+* plugins are encouraged (but not required) to prefix their specific options
+ with their name (``qbzr.`` for qbzr)
+
+* collisions are detected at registration time so users are protected from
+ incompatibilities between plugins,
+
+* options that need to be used by several plugins (or shared between ``bzr``
+ core and plugins) should be discussed but these discussions are already
+ happening so the risk of misuse is low enough.
+
+Value
+-----
+
+All option values are text. They are provided as Unicode strings to API
+users with some refinements:
+
+* boolean values can be obtained for a set of acceptable strings (yes/no,
+ y/n, on/off, etc), (implemented with the ``from_unicode`` parameter)
+
+* a list of strings from a value containing a comma separated list of
+ strings.
+
+Since the configuration files can be edited by the user, ``bzr`` doesn't
+expect their content to be valid at all times. Instead, the code using
+options should be ready to handle *invalid* values by warning the user and
+falling back to a default value.
+
+Likely, if an option is not defined in any configuration file, the code
+should fallback to a default value (helpers should be provided by the API to
+handle common cases: warning the user, getting a particular type of value,
+returning a default value)(most of that is now handled at Option definition).
+
+This also ensures compatibility with values provided via environment
+variables or from the command line (where no validation can be expected
+either)(done in the new design).
+
+
+Option expansion
+----------------
+
+Some option values can be templates and contain references to other
+options. This is especially useful to define URLs in sections shared for
+multiple branches for example. It can also be used to describe commands
+where some parameters are set by ``bzrlib`` at runtime.
+
+Since option values are text-only, and to avoid clashing with other option
+expansion (also known as interpolation) syntaxes, references are enclosed
+with curly brackets::
+
+ push_location = lp:~{launchpad_username}/bzr/{nick}
+
+In the example above, ``launchpad_username`` is an already defined
+configuration option while ``nick`` is the branch nickname and is set when a
+configuration applies to a given branch.
+
+The interpolation implementation should accept an additional dict so that
+``bzrlib`` or plugins can define references that can be expanded without
+being existing configuration options::
+
+ diff_command={cmd} {cmd_opts} {file_a} {file_b}
+
+There are two common errors that should be handled when handling interpolation:
+
+* loops: when a configuration value refers to itself, directly or indirectly,
+
+* undefined references: when a configuration value refers to an unknown option.
+
+The loop handling can be modified to allow cross-sections and cross-files
+interpolation: if an option refers to itself (directly or indirectly) during
+an expansion, the fallback sections or files can be queried for its value.
+
+This allows list values to refer to the definition in the less specific
+configurations::
+
+ bazaar.conf:
+ debug_flags = hpss
+
+ branch.conf for mybranch:
+ debug_flags = {debug_flags}, hpssdetail
+
+ $ bzr -d mybranch config debug_flags
+ hpss, hpssdetail
+
+Undefined references are detected if they are not defined in any
+configuration. This will trigger errors while displaying the value. Diagnosing
+typos should be doable in this case.
+
+Configuration file syntax
+-------------------------
+
+The configuration file is mostly an ``ini-file``. It contains ``name = value``
+lines grouped in sections. A section starts with a string enclosed in squared
+brackets ('[section_name]`), this string uniquely identifies the section in
+the file. Comments are allowed by prefixing them with the '#' character.
+
+A section is named by the path (or some other unuique identifier) it should
+apply to (more examples below).
+
+When sections are used, they provide a finer grain of configuration by
+defining option sets that apply to some working trees, branches,
+repositories (or any kind of context) or part of them. The relationship
+between a given context and the sections it applies to is defined by the
+config file.
+
+So far, Bazaar uses a glob in ``locations.conf`` and select the sections
+that apply to a given url (or a local path).
+
+The subset is defined by the common leading path or a glob.
+
+Different kinds of section names can be defined:
+
+* a full url: used to described options for remote branches and
+ repositories (LocationMatcher supports this).
+
+* local absolute path: used for working trees, branches or repositories
+ on the local disks (LocationMatcher supports this).
+
+* relative path: the path is relative to the configuration file and can be
+ used for colocated branches or threads in a loom, i.e any working tree,
+ branch or repository that is located in a place related to the
+ configuration file path. Some configuration files may define this path
+ relationship in specific ways to make them easier to use (i.e. if a config
+ file is somewhere below ``.bzr`` and refers to threads in a loom for
+ example, the relative path would be the thread name, it doesn't have to be
+ an *exact* relative path, as long as its interpretation is unambiguous and
+ clear for the user) (No section matchers support this so far, needs to
+ file a bug)
+
+Section matching
+----------------
+
+Section names define another name space (than the option names one) with an
+entirely different purpose: in a given configuration file, for a given
+context, only some sections will be relevant and will be queried in a
+specific order.
+
+This matching is specific to each config file and implemented by the
+SectionMatcher objects.
+
+Whatever this matching does, the user can observe the results with the ``bzr
+config`` command which displays the sections in the order they are queried.
+
+LocationMatcher
+~~~~~~~~~~~~~~~
+
+The context here is either:
+
+* an URL,
+
+* a local path.
+
+Note that for both the provided context and the section names, if an URL uses
+a ``file:///`` form, it is converted to a local path.
+
+The sections names can use globs for each path component
+(i.e. ``/dir/*/subdir`` is allowed but ``/dir/\*\*/subdir`` will match
+``/dir/a/subdir`` but not ``/dir/a/b/subdir``.
+
+The reason is that the ordering is defined by sorting the section names
+matching the context on the number of path components followed by the path
+itself in lexicographical order. This results in most specific sections being
+queried before the more generic ones.
+
+PathMatcher
+~~~~~~~~~~~
+
+``LocationMatcher`` has some obscure (for unaware users) edge cases and
+limitations that can be surprising. ``PathMatcher`` aims at addressing these
+issues by providing simpler rules while still giving full control to the
+user (http://pad.lv/832046).
+
+The context here is a local path, absolute or relative. If the path is
+relative it is interpreted from the file base directory.
+
+Note that 'base directory' for configuration files in Bazaar directories is
+really:
+
+* the home directory for files under ``~/.bazaar``,
+
+* the ``.bzr`` base directory for files under ``.bzr``.
+
+The order is the one observed in the file so most generic values are specified
+first and most specific ones last. As such, the order in the file is the
+opposite of the one displayed by ``bzr config`` which displays most specific
+values first. This seems to be the most natural order in both cases.
+
+A section matches if the section name is a prefix of the context path
+(relative paths being converted to absolute on the fly).
+
+The Option object
+-----------------
+
+(copied from a recent version of bzr.dev for easier reading, refer to the
+original for an up to date version)
+
+The Option object is used to define its properties:
+
+* name: a name: a valid python identifier (even if it's not used as an
+ identifier in python itself). This is also used to register the option.
+
+* default: the default value that Stack.get() should return if no
+ value can be found for the option.
+
+* default_from_env: a list of environment variables. The first variable set
+ will provide a default value overriding 'default' which remains the
+ default value if *no* environment variable is set.
+
+* help: a doc string describing the option, the first line should be a
+ summary and can be followed by a blank line and a more detailed
+ explanation.
+
+* from_unicode: a callable accepting a unicode string and returning a
+ suitable value for the option. If the string cannot be coerced it should
+ return None.
+
+* invalid: the action to be taken when an invalid value is encountered in a
+ store (during a Stack.get()).
+
+The Section object
+------------------
+
+Options are grouped into sections which share some properties with the well
+known dict objects:
+
+* the key is the name,
+* you can get, set and remove an option,
+* the value is a unicode string.
+
+MutableSection is needed to set or remove an option, ReadOnlySection should
+be used otherwise.
+
+The Store object
+----------------
+
+This is an implementation-level object that should rarely be used directly.
+
+* it can be local or remote
+
+* locking
+
+ All lock operations should be implemented via transport objects. (True for
+ Store).
+
+* option life cycle
+
+ Working trees, branches and repositories should define a config attribute
+ following the same life cycle as their lock: the associated config file is
+ read once and written once if needed. This should minimize the file system
+ accesses or the network requests. There is no known racing scenarios for
+ configuration options, changing the existing implementation to this less
+ constrained one shouldn't introduce any. Yet, in order to detect such
+ racing scenarios, we can add a check that the current content of the
+ configuration file is the expected one before writing the new content and
+ emit warnings if differences occur. The checks should be performed for the
+ modified values only. As of today (and in the foreseeable future), the
+ size of the configuration files are small enough to be kept in memory (see
+ http://pad.lv/832042).
+
+The Stack object
+-----------------
+
+This the object that provides access to the needed features:
+
+* getting an option value,
+
+* setting an option value,
+
+* deleting an option value,
+
+* handling a list of configuration files and for each of them a section
+ matcher providing the sections that should be tried in the given order to
+ find an option.
+
+* handling a Store and a section where option creation, modification and
+ deletion will occur.
+
+Depending on the files involved, a working tree, branch or repository object
+(or more generally a context) should be provided to access the corresponding
+configuration files. Note that providing a working tree object also
+implicitly provides the associated branch and repository object so only one
+of them is required (or none for configuration files specific to the user
+like ``bazaar.conf``).
+
+Getting an option value
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Depending on the option, there are various places where it can be defined
+and several ways to override these settings when needed.
+
+The following lists all possible places where a configuration option can
+be defined, but some options will make sense in only some of them. The
+first to define a value for an option wins (None is therefore used to
+express that an option is not set).
+
+* command-line
+ ``-Ooption=value`` see http://pad.lv/491196.
+
+* ``~/.bazaar/locations.conf``
+
+ When an option is set in ``locations.conf`` it overrides any other
+ configuration file. This should be used with care as it allows setting a
+ different value than what is recommended by the project
+
+* ``tree`` (Not Implemented Yet)
+
+ The options related to the working tree.
+
+ This includes all options related to commits, ignored files, junk files,
+ etc.
+
+ Note that the sections defined there can use relative paths if some
+ options should apply to a subtree or some specific files only.
+
+ See http://pad.lv/430538 and http://pad.lv/654998.
+
+* ``branch`` located in ``.bzr/branch/branch.conf``
+
+ The options related to the branch.
+
+ Sections can be defined for colocated branches or loom threads.
+
+* ``repository`` (Not Implemented Yet)
+
+ The options related to the repository.
+
+ Using an option to describe whether or not a repository is shared could
+ help address http://pad.lv/342119 but this will probably requires a format
+ bump).
+
+* ``project`` (Not Implemented Yet)
+
+ The options common to all branches and working trees for a project.
+
+* ``organization`` (Not Implemented Yet)
+
+ The options common to all branches and working trees for an organization.
+
+ See http://pad.lv/419854.
+
+* ``system`` (Not Implemented Yet but see http://pad.lv/419854 and
+ https://code.launchpad.net/~thomir/bzr/add-global-config/+merge/69592)
+
+ The options common to all users of a system (may be /etc/bzr/defaults
+ or /usr/local/etc/bzr/defaults or
+ /Library/Preferences/com.canonical.defaults or c:\windows\bazaar.conf
+ (someone fix this one please ;) depending on the OS).
+
+* ``bazaar.conf``
+
+ The options the user has selected for the host he is using.
+
+ Sections can be defined for both remote and local branches to define
+ default values (i.e. the most common use of ``locations.conf`` today).
+
+* default (implemented by the OptionRegistry)
+
+ The options defined in the ``bzr`` source code.
+
+ This will be implemented via the Option objects.
+
+Plugins can define additional configuration files as they see fit and
+insert them in this list, see their documentation for details.
+
+Compatibility
+=============
+
+There are ways to keep the same files while ensuring compatibility via various
+tricks but there are cases where using new files to replace the old ones is
+definitely easier:
+
+* no need to ensure that the new files are correctly handled by old bzr
+ versions,
+
+* making it clear for users that there is a switch and let them migrate at
+ their own pace.
+
+The known cases so far are described below.
+
+Obvious at this point:
+
+* Branch provides ``get_config`` for the old design and ``get_config_stack``
+ for the new design so that both designs are supported. Once the store
+ sharing is implemented, we may want to use an attribute for the stack and
+ deprecate both ``get_config`` and ``get_config_stack``.
+
+* Sections names in ``bazaar.conf`` are arbitrary (except ``DEFAULT``) so
+ it's easier to leave the file untouched and let plugin authors and users
+ migrate away (or not) from them. For ``bzr`` itself, that means
+ ``DEFAULT`` is the only section used for most of the options and provides
+ user defaults. ``ALIASES`` requires a specific stack but only the ``bzr
+ alias`` command cares about that.
+
+* Option policies should be deprecated:
+
+ * The ``norecurse`` policy is useless, all options are recursive by
+ default. If specific values are needed for specific paths, they can just
+ be defined as such (in the appropriate sections or files).
+
+ * The ``appendpath`` policy should be implemented via interpolation and a
+ ``relpath`` option provided by the configuration framework
+ (http://pad.lv/832013).
+
+* Section order in ``locations.conf`` has issues which make a migration to a
+ different way to organize the sections (hence the file content) far easier
+ with a new file.
+
+* ``locations.conf`` is really for overrides but many users have been using it
+ to provide defaults. There is no way to know if the whole content has been
+ used for defaults or overrides or a mix of both. So there is no way to
+ migrate this automatically.
+
+Unclear at this point:
+
+* [BOOKMARKS] section can be replaced by ``bookmarks.xxx`` options (the
+ bookmarks plugins already uses ``bookmarks_xxx`` in branch.conf since no
+ sections were supported there). The easiest here is probably to just merge
+ the plugin into core and use the appropriate option names consistently. A
+ ``config:`` directory service may even be better as any option can be used
+ as a bookmark. This allows things like::
+
+ [/whatever/path]
+ my_push = lp:<launchpad.login>/xxx/{nick}
+ web_site=ftp://example.com/
+
+ bzr push config:web_site
+
+ Which means we completely replace the plugin and don't need to care about
+ migrating the section.
+
+* [ALIASES] section can be replaced by corresponding bzr.alias.xxx
+ options. This could be automated by creating the corresponding options ?
+
+* I don't know about other sections, feedback welcome. Plugin authors are
+ encouraged to migrate to the new name space scheme by prefixing their
+ options with their plugin name.
+
+Notes
+=====
+
+These are random notes about concepts, ideas or issues not implemented yet.
+
+Developer facing concepts
+-------------------------
+
+Option
+~~~~~~
+
+* list of allowed Config IDs (this allows a list of possible config files in
+ bazaar.conf only option and use it while bootstrapping the config
+ creations).
+
+* blacklist of config IDs (some options *can't* be stored (modified) by the
+ user)
+
+An alternative is to just let the devs decide which stack they use for a
+given option, ``stacked_on_location`` for example is said to relate to the
+branch only and changing it or setting it in a different config file may not
+be appropriate. This may not be a good example as there is also the
+``default_stack_on`` option which can be set only in ``control.conf``
+though...
+
+Stack
+~~~~~
+
+* a lazy cache for the option values (should be reset on modifications as
+ interpolations will make it tricky to update incrementally) (see FIXME in
+ config.py Stack.get()))
+
+* ensures that the Stores involved generate as less IOs as possible (see
+ http://pad.lv/832042)
+
+* ensures that the transaction is the object life time (i.e. modifications
+ will be taken into account *iff* they are committed explicitly).
+
+StackRegistry
+~~~~~~~~~~~~~
+
+* ensures that a config ID is a unique identifier
+* register Stacks
+
+Store
+~~~~~
+
+* ensures that the transaction is the object life time (i.e. modifications
+ will be taken into account *iff* they are committed explicitly).
+
+Examples
+--------
+
+store examples:
+~~~~~~~~~~~~~~~
+
+* ConfigObj (bazaar.conf)
+
+* DB (<scheme>://bazaar.launchpad.net/bazaar.conf)
+
+
+Why and when locking config files matter
+----------------------------------------
+
+This is relevant for http://pad.lv/832042.
+
+``bzr`` behavior, as well as the objects it acts upon, is configured via a
+set of so-called configuration files.
+
+These files allow to define working trees, branches and repositories, their
+relationships and how ``bzr`` should handle them.
+
+The default behavior of ``bzr`` is aimed at making this configuration as
+transparent as possible by keeping track of how these objects are created
+and modified when they are used. In short, they are useless until you want
+to change the default behavior in some specific context.
+
+We mostly **read** config options. Therefore all we care about is to
+guarantee that:
+
+* we get a valid config file at all times when reading,
+
+* we always leave a valid config file when writing (via the rename dance)
+
+From there, conceptually, all operations can clearly define whether or not
+they need to modify a config file and do so only when they succeed. All
+modifications occurring during such an operation are delayed until the very
+end of the operation.
+
+Now, we want to minimize the overlapping times where one bzr operation has
+changed a value and another concurrent operation is unaware of this
+modification.
+
+These overlapping periods are *as of today* rare.
+
+The only known case, http://pad.lv/525571 has been fixed in bzr-2.1.3. The
+bug there was triggered when two processes tried to write the same config
+file at the same time leaving an invalid file in the end.
+
+Such a period can be recognized and detected though: when changing an option
+value, if the preserved original value is different in the config file,
+someone else modified it and the operation can be invalid because it relied
+on the original value.
+
+For the sake of the example, if an option value represent a global unique ID
+via a simple counter (very bad idea), if two operations try to increment it,
+both will use the same value that won't be unique anymore. Checking the
+value present in the file when trying to save the updated value with
+identify such a collision.
+
+An assumption is floating around: it should be enough to report when an
+operation is modifying an already modified option and observe that no-one
+reports such occurrences.
+
+Note that this assumption is made in a context where *no* known scenarios
+exist in the bzr code base not in any plugin (for a best effort value of
+'any', feedback highly welcome, bug reports even ;)
+
+With this in mind, we can change the definition of config options, stores
+and stacks to ensure that:
+
+* a config file is read only once when in read access,
+
+* a config file is read only once and written only once when in write
+ access, adding the check mentioned above will require *one* additional
+ read.
+
+A reader can then safely assume that reading a config file gives it a valid
+(and coherent) definition of the configuration when the operation
+starts. All the operation has to do is to declare which config files may be
+modified by an operation (whether or not we can be liberal on this 'may be'
+is yet to be defined).
diff --git a/doc/developers/overview.txt b/doc/developers/overview.txt
new file mode 100644
index 0000000..ceb03f5
--- /dev/null
+++ b/doc/developers/overview.txt
@@ -0,0 +1,431 @@
+=============================
+Bazaar Architectural Overview
+=============================
+
+This document describes the key classes and concepts within Bazaar. It is
+intended to be useful to people working on the Bazaar codebase, or to
+people writing plugins. People writing plugins may also like to read the
+guide to `Integrating with Bazaar <integration.html>`_ for some specific recipes.
+
+There's some overlap between this and the `Core Concepts`_ section of the
+user guide, but this document is targetted to people interested in the
+internals. In particular the user guide doesn't go any deeper than
+"revision", because regular users don't care about lower-level details
+like inventories, but this guide does.
+
+If you have any questions, or if something seems to be incorrect, unclear
+or missing, please talk to us in ``irc://irc.freenode.net/#bzr``, write to
+the Bazaar mailing list, or simply file a bug report.
+
+
+IDs and keys
+############
+
+IDs
+===
+
+All IDs are globally unique identifiers. Inside bzrlib they are almost
+always represented as UTF-8 encoded bytestrings (i.e. ``str`` objects).
+
+The main two IDs are:
+
+:Revision IDs: The unique identifier of a single revision, such as
+ ``pqm@pqm.ubuntu.com-20110201161347-ao76mv267gc1b5v2``
+:File IDs: The unique identifier of a single file.
+
+By convention, in the bzrlib API, parameters of methods that are expected
+to be IDs (as opposed to keys, revision numbers, or some other handle)
+will end in ``id``, e.g. ``revid`` or ``file_id``.
+
+Ids may be stored directly or they can be inferred from other
+data. Native Bazaar formats store ids directly; foreign VCS
+support usually generates them somehow. For example, the
+Git commit with SHA ``fb235a3be6372e40ff7f7ebbcd7905a08cb04444``
+is referred to with the revision ID
+``git-v1:fb235a3be6372e40ff7f7ebbcd7905a08cb04444``. IDs are expected
+to be persistent
+
+File ids
+--------
+
+File ids are unique identifiers for files. There are three slightly different
+categories of file ids.
+
+Tree file ids
+~~~~~~~~~~~~~
+
+Tree file ids are used in the ``Tree`` API and can either be UTF-8 encoded
+bytestrings or tuples of UTF-8 encoded bytestrings. Plain bytestrings
+are considered to be the equivalent of a 1-tuple containing that
+bytestring.
+
+Tree file ids should be considered valid only for a specific tree context.
+Note that this is a stricter interpretation than what the current bzr
+format implementation provides - its file ids are persistent across runs
+and across revisions.
+
+For some formats (most notably bzr's own formats) it's possible for the
+implementation to specify the file id to use. In other case the tree
+mandates a specific file id.
+
+Inventory file ids
+~~~~~~~~~~~~~~~~~~
+
+Inventories are specific to the bzr native format and are the main layer
+below the ``Tree`` implementation of bzr. File ids in inventories can
+only be UTF-8 encoded bytestrings. A single Tree object can be associated
+with multiple inventories if there are nested trees.
+
+Tree file ids for bzr formats are a tuple of inventory file ids for the file
+in question. Each non-last item in the tuple refers to the tree
+reference of an inner tree. The last item in the tuple refers to the
+actual file. This means that lookups of file ids doesn't scale with
+the number of nested trees.
+
+Inventory file ids are only relevant for native Bazaar formats; foreign
+formats don't use inventories.
+
+Transform ids
+~~~~~~~~~~~~~
+
+Transform ids are used during tree transform operations (used by e.g. merge).
+The same transform id is expected to be used for two instances of the
+same file. At the moment transform ids are directly derived from file
+ids, but in the future they could be based on other data too (e.g.
+automatic rename detection or format-specific rules).
+
+Keys
+====
+
+A composite of one or more ID elements. E.g. a (file-id, revision-id)
+pair is the key to the "texts" store, but a single element key of
+(revision-id) is the key to the "revisions" store.
+
+
+Core classes
+############
+
+Transport
+=========
+
+The ``Transport`` layer handles access to local or remote directories.
+Each Transport object acts as a logical connection to a particular
+directory, and it allows various operations on files within it. You can
+*clone* a transport to get a new Transport connected to a subdirectory or
+parent directory.
+
+Transports are not used for access to the working tree. At present
+working trees are always local and they are accessed through the regular
+Python file I/O mechanisms.
+
+Filenames vs URLs
+-----------------
+
+Transports work in terms of URLs. Take note that URLs are by definition
+only ASCII - the decision of how to encode a Unicode string into a URL
+must be taken at a higher level, typically in the Store. (Note that
+Stores also escape filenames which cannot be safely stored on all
+filesystems, but this is a different level.)
+
+The main reason for this is that it's not possible to safely roundtrip a
+URL into Unicode and then back into the same URL. The URL standard
+gives a way to represent non-ASCII bytes in ASCII (as %-escapes), but
+doesn't say how those bytes represent non-ASCII characters. (They're not
+guaranteed to be UTF-8 -- that is common but doesn't happen everywhere.)
+
+For example, if the user enters the URL ``http://example/%e0``, there's no
+way to tell whether that character represents "latin small letter a with
+grave" in iso-8859-1, or "latin small letter r with acute" in iso-8859-2,
+or malformed UTF-8. So we can't convert the URL to Unicode reliably.
+
+Equally problematic is if we're given a URL-like string containing
+(unescaped) non-ASCII characters (such as the accented a). We can't be
+sure how to convert that to a valid (i.e. ASCII-only) URL, because we
+don't know what encoding the server expects for those characters.
+(Although it is not totally reliable, we might still accept these and
+assume that they should be put into UTF-8.)
+
+A similar edge case is that the URL ``http://foo/sweet%2Fsour`` contains
+one directory component whose name is "sweet/sour". The escaped slash is
+not a directory separator, but if we try to convert the URL to a regular
+Unicode path, this information will be lost.
+
+This implies that Transports must natively deal with URLs. For simplicity
+they *only* deal with URLs; conversion of other strings to URLs is done
+elsewhere. Information that Transports return, such as from ``list_dir``,
+is also in the form of URL components.
+
+More information
+----------------
+
+See also:
+
+* `Developer guide to bzrlib transports <transports.html>`_
+* API docs for ``bzrlib.transport.Transport``
+
+Control directory
+=================
+
+Each control directory (such as ".bzr/") can contain zero or one
+repositories, zero or one working trees and zero or more branches.
+
+The ``BzrDir`` class is the ``ControlDir`` implementation that is
+responsible for the ".bzr/" directory and its implementation. Plugins
+that provide support for other version control systems can provide
+other subclasses of ``ControlDir``.
+
+Tree
+====
+
+A representation of a directory of files (and other directories and
+symlinks etc). The most important kinds of Tree are:
+
+:WorkingTree: the files on disk editable by the user
+:RevisionTree: a tree as recorded at some point in the past
+
+Trees can map file paths to file-ids and vice versa (although trees such
+as WorkingTree may have unversioned files not described in that mapping).
+Trees have an inventory and parents (an ordered list of zero or more
+revision IDs).
+
+The implementation of ``Tree`` for Bazaar's own formats is based around
+``Inventory`` objects which describe the shape of the tree. Each tree has
+at least one inventory associated with it, which is available as the
+``root_inventory`` attribute on tree. The tree can have more inventories
+associated with it if there are references to other trees in it. These
+references are indicated with ``tree-reference`` inventory entry at the
+point where the other tree is nested. The tree reference entry contains
+sufficient information for looking up the inventory associated with the
+nested tree. There can be multiple layers of nesting.
+
+Not each ``Tree`` implementation will necessarily have an associated
+``root_inventory``, as not all implementations of ``Tree`` are based
+around inventories (most notably, implementations of foreign VCS file
+formats).
+
+WorkingTree
+===========
+
+A workingtree is a special type of Tree that's associated with a working
+directory on disk, where the user can directly modify the files.
+
+Responsibilities:
+
+* Maintaining a WorkingTree on disk at a file path.
+* Maintaining the basis inventory (the inventory of the last commit done)
+* Maintaining the working inventory.
+* Maintaining the pending merges list.
+* Maintaining the stat cache.
+* Maintaining the last revision the working tree was updated to.
+* Knows where its Branch is located.
+
+Dependencies:
+
+* a Branch
+* local access to the working tree
+
+
+Branch
+======
+
+A Branch is a key user concept - its a single line of history that one or
+more people have been committing to.
+
+A Branch is responsible for:
+
+* Holding user preferences that are set in a Branch.
+* Holding the 'tip': the last revision to be committed to this Branch.
+ (And the revno of that revision.)
+* Knowing how to open the Repository that holds its history.
+* Allowing write locks to be taken out to prevent concurrent alterations to the branch.
+
+Depends on:
+
+* URL access to its base directory.
+* A Transport to access its files.
+* A Repository to hold its history.
+
+
+Repository
+==========
+
+Repositories store committed history: file texts, revisions, inventories,
+and graph relationships between them. A repository holds a bag of
+revision data that can be pointed to by various branches:
+
+* Maintains storage of various history data at a URL:
+
+ * Revisions (Must have a matching inventory)
+ * Digital Signatures
+ * Inventories for each Revision. (Must have all the file texts available).
+ * File texts
+
+* Synchronizes concurrent access to the repository by different
+ processes. (Most repository implementations use a physical mutex only
+ for a short period, and effectively support multiple readers and
+ writers.)
+
+Stacked Repositories
+--------------------
+
+A repository can be configured to refer to a list of "fallback"
+repositories. If a particular revision is not present in the original
+repository, it refers the query to the fallbacks.
+
+Compression deltas don't span physical repository boundaries. So the
+first commit to a new, empty repository with fallback repositories will
+store a full text of the inventory, and of every new file text.
+
+At runtime, repository stacking is actually configured by the branch, not
+the repository. So doing ``a_bzrdir.open_repository()``
+gets you just the single physical repository, while
+``a_bzrdir.open_branch().repository`` gets one configured with a stacking.
+Therefore, to permanently change the fallback repository stored on disk,
+you must use ``Branch.set_stacked_on_url``.
+
+Changing away from an existing stacked-on URL will copy across any
+necessary history so that the repository remains usable.
+
+A repository opened from an HPSS server is never stacked on the server
+side, because this could cause complexity or security problems with the
+server acting as a proxy for the client. Instead, the branch on the
+server exposes the stacked-on URL and the client can open that.
+
+
+Storage model
+#############
+
+This section describes the model for how bzr stores its data. The
+representation of that data on disk varies considerable depending on the
+format of the repository (and to a lesser extent the format of the branch
+and working tree), but ultimately the set of objects being represented is
+the same.
+
+Branch
+======
+
+A branch directly contains:
+
+* the ID of the current revision that branch (a.k.a. the “tip”)
+* some settings for that branch (the values in “branch.conf”)
+* the set of tags for that branch (not supported in all formats)
+
+A branch implicitly references:
+
+* A repository. The repository might be colocated in the same directory
+ as the branch, or it might be somewhere else entirely.
+
+
+Repository
+==========
+
+A repository contains:
+
+* a revision store
+* an inventory store
+* a text store
+* a signature store
+
+A store is a key-value mapping. This says nothing about the layout on
+disk, just that conceptually there are distinct stores, each with a
+separate namespace for the keys. Internally the repository may serialize
+stores in the same file, and/or e.g. apply compression algorithms that
+combine records from separate stores in one block, etc.
+
+You can consider the repository as a single key space, with keys that look
+like *(store-name, ...)*. For example, *('revisions',
+revision-id)* or *('texts', revision-id, file-id)*.
+
+Revision store
+--------------
+
+Stores revision objects. The keys are GUIDs. The value is a revision
+object (the exact representation on disk depends on the repository
+format).
+
+As described in `Core Concepts`_ a revision describes a snapshot of the
+tree of files and some metadata about them.
+
+* metadata:
+
+ * parent revisions (an ordered sequence of zero or more revision IDs)
+ * commit message
+ * author(s)
+ * timestamp
+ * (and all other revision properties)
+
+* an inventory ID (that inventory describes the tree contents). Is often
+ the same as the revision ID, but doesn't have to be (e.g. if no files
+ were changed between two revisions then both revisions will refer to
+ the same inventory).
+
+
+Inventory store
+---------------
+
+Stores inventory objects. The keys are GUIDs. (Footnote: there will
+usually be a revision with the same key in the revision store, but there
+are rare cases where this is not true.)
+
+An inventory object contains:
+
+* a set of inventory entries
+
+An inventory entry has the following attributes
+
+* a file-id (a GUID, or the special value TREE_ROOT for the root entry of
+ inventories created by older versions of bzr)
+* a revision-id, a GUID (generally corresponding to the ID of a
+ revision). The combination of (file-id, revision-id) is a key into the
+ texts store.
+* a kind: one of file, directory, symlink, tree-reference (tree-reference
+ is only supported in unsupported developer formats)
+* parent-id: the file-id of the directory that contains this entry (this
+ value is unset for the root of the tree).
+* name: the name of the file/directory/etc in that parent directory
+* executable: a flag indicating if the executable bit is set for that
+ file.
+
+An inventory entry will have other attributes, depending on the kind:
+
+* file:
+
+ * SHA1
+ * size
+
+* directory
+
+ * children
+
+* symlink
+
+ * symlink_target
+
+* tree-reference
+
+ * reference_revision
+
+For some more details see `Inventories <inventory.html>`_.
+
+
+Texts store
+-----------
+
+Stores the contents of individual versions of files. The keys are pairs
+of (file-id, revision-id), and the values are the full content (or
+"text") of a version of a file.
+
+For consistency/simplicity text records exist for all inventory entries,
+but in general only entries with of kind "file" have interesting records.
+
+
+Signature store
+---------------
+
+Stores cryptographic signatures of revision contents. The keys match
+those of the revision store.
+
+.. _Core Concepts: http://doc.bazaar.canonical.com/latest/en/user-guide/core_concepts.html
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/packrepo.txt b/doc/developers/packrepo.txt
new file mode 100644
index 0000000..dc31aa7
--- /dev/null
+++ b/doc/developers/packrepo.txt
@@ -0,0 +1,287 @@
+==========================
+KnitPack repository format
+==========================
+
+.. contents::
+
+Using KnitPack repositories
+===========================
+
+Motivation
+----------
+
+KnitPack is a new repository format for Bazaar, which is expected to be
+faster both locally and over the network, is usually more compact, and
+will work with more FTP servers.
+
+Our benchmarking results to date have been very promising. We fully expect
+to make a pack-based format the default in the near future. We would
+therefore like as many people as possible using KnitPack repositories,
+benchmarking the results and telling us where improvements are still needed.
+
+Preparation
+-----------
+
+A small percentage of existing repositories may have some inconsistent
+data within them. It's is a good idea to check the integrity of your
+repositories before migrating them to knitpack format. To do this, run::
+
+ bzr check
+
+If that reports a problem, run this command::
+
+ bzr reconcile
+
+Note that this can take many hours for repositories with deep history
+so be sure to set aside some time for this if it is required.
+
+Creating a new knitpack branch
+------------------------------
+
+If you're starting a project from scratch, it's easy to make it a
+``knitpack`` one. Here's how::
+
+ cd my-stuff
+ bzr init --pack-0.92
+ bzr add
+ bzr commit -m "initial import"
+
+In other words, use the normal sequence of commands but add the
+``--pack-0.92`` option to the ``init`` command.
+
+**Note:** In bzr 0.92, this format was called ``knitpack-experimental``.
+
+Creating a new knitpack repository
+----------------------------------
+
+If you're starting a project from scratch and wish to use a shared repository
+for branches, you can make it a ``knitpack`` repository like this::
+
+ cd my-repo
+ bzr init-repo --pack-0.92 .
+ cd my-stuff
+ bzr init
+ bzr add
+ bzr commit -m "initial import"
+
+In other words, use the normal sequence of commands but add the
+``--pack-0.92`` option to the ``init-repo`` command.
+
+Upgrading an existing branch or repository to knitpack format
+-------------------------------------------------------------
+
+If you have an existing branch and wish to migrate it to
+a ``knitpack`` format, use the ``upgrade`` command like this::
+
+ bzr upgrade --pack-0.92 path-to-my-branch
+
+If you are using a shared repository, run::
+
+ bzr upgrade --pack-0.92 ROOT_OF_REPOSITORY
+
+to upgrade the history database. Note that this will not
+alter the branch format of each branch, so
+you will need to also upgrade each branch individually
+if you are upgrading from an old (e.g. < 0.17) bzr.
+More modern bzr's will already have the branch format at
+our latest branch format which adds support for tags.
+
+Starting a new knitpack branch from one in an older format
+----------------------------------------------------------
+
+This can be done in one of several ways:
+
+1. Create a new branch and pull into it
+2. Create a standalone branch and upgrade its format
+3. Create a knitpack shared repository and branch into it
+
+Here are the commands for using the ``pull`` approach::
+
+ bzr init --pack-0.92 my-new-branch
+ cd my-new-branch
+ bzr pull my-source-branch
+
+Here are the commands for using the ``upgrade`` approach::
+
+ bzr branch my-source-branch my-new-branch
+ cd my-new-branch
+ bzr upgrade --pack-0.92 .
+
+Here are the commands for the shared repository approach::
+
+ cd my-repo
+ bzr init-repo --pack-0.92 .
+ bzr branch my-source-branch my-new-branch
+ cd my-new-branch
+
+As a reminder, any of the above approaches can fail if the source branch
+has inconsistent data within it and hasn't been reconciled yet. Please
+be sure to check that before reporting problems.
+
+Testing packs for bzr-svn users
+-------------------------------
+
+If you are using ``bzr-svn`` or are testing the prototype subtree support,
+you can still use and assist in testing KnitPacks. The commands to use
+are identical to the ones given above except that the name of the format
+to use is ``knitpack-subtree-experimental``.
+
+WARNING: Note that the subtree formats, ``dirstate-subtree`` and
+``knitpack-subtree-experimental``, are **not** production strength yet and
+may cause unexpected problems. They are required for the bzr-svn
+plug-in but should otherwise only be used by people happy to live on the
+bleeding edge. If you are using bzr-svn, you're on the bleeding edge anyway.
+:-)
+
+Reporting problems
+------------------
+
+If you need any help or encounter any problems, please contact the developers
+via the usual ways, i.e. chat to us on IRC or send a message to our mailing
+list. See http://wiki.bazaar.canonical.com/BzrSupport for contact details.
+
+
+Technical notes
+===============
+
+Bazaar 0.92 adds a new format (experimental at first) implemented in
+``bzrlib.repofmt.pack_repo.py``.
+
+This format provides a knit-like interface which is quite compatible
+with knit format repositories: you can get a VersionedFile for a
+particular file-id, or for revisions, or for the inventory, even though
+these do not correspond to single files on disk.
+
+The on-disk format is that the repository directory contains these
+files and subdirectories:
+
+==================== =============================================
+packs/ completed readonly packs
+indices/ indices for completed packs
+upload/ temporary files for packs currently being
+ written
+obsolete_packs/ packs that have been repacked and are no
+ longer normally needed
+pack-names index of all live packs
+lock/ lockdir
+==================== =============================================
+
+Note that for consistency we always write "indices" not "indexes".
+
+This is implemented on top of pack files, which are written once from
+start to end, then left alone. A pack consists of a body file, plus
+several index files. There are four index files for each pack, which
+have the same basename and an extension indicating the purpose of the
+index:
+
+======== ========== ======================== ==========================
+extn Purpose Key References
+======== ========== ======================== ==========================
+``.tix`` File texts ``file_id, revision_id`` per-file parents,
+ compression basis
+ per-file parents
+``.six`` Signatures ``revision_id,`` -
+``.rix`` Revisions ``revision_id,`` revision parents
+``.iix`` Inventory ``revision_id,`` revision parents,
+ compression base
+======== ========== ======================== ==========================
+
+Indices are accessed through the ``bzrlib.index.GraphIndex`` class.
+Indices are stored as sorted files on disk. Each line is one record,
+and contains:
+
+ * key fields
+ * a value string - for all these indices, this is an ascii decimal pair
+ of "offset length" giving the position of the referenced data within
+ the pack body file
+ * a list of zero or more reference lists
+
+The reference lists let a graph be stored within the index. Each
+reference list entry points to another entry in the same index. The
+references are represented as a byte offset for the target within the
+index file.
+
+When a compression base is given, it indicates that the body of the text
+or inventory is a forward delta from the referenced revision. The
+compression base list must have length 0 or 1.
+
+Like packs, indexes are written only once and then unmodified. A
+GraphIndex builder is a mutable in-memory graph that can be sorted,
+cross-referenced and written out when the write group completes.
+
+There can also be index entries with a value of 'a' for absent. These
+records exist just to be pointed to in a graph. This is used, for
+example, to give the revision-parent pointer when the parent revision is
+in a previous pack.
+
+The data content for each record is a knit data chunk. The knits are
+always unannotated - the annotations must be generated when needed.
+(We'd like to cache/memoize the annotations.) The data hunks can be
+moved between packs without needing to recompress them.
+
+It is not possible to regenerate an index from the body file, because it
+contains information stored in the knit index that's not in the body.
+(In particular, the per-file graph is only stored in the index.)
+We would like to change this in a future format.
+
+The lock is a regular LockDir lock. The lock is only held for a much
+reduced scope, while updating the pack-names file. The bulk of the
+insertion can be done without the repository locked. This is an
+implementation detail; the repository user should still call
+``repository.lock_write`` at the regular time but be aware this does not
+correspond to a physical mutex.
+
+Read locks control caching but do not affect writers.
+
+The newly-added repository write group concept is very important to
+KnitPack repositories. When ``start_write_group`` is called, a new
+temporary pack is created and all modifications to the repository will
+go into it until either ``commit_write_group`` or ``abort_write_group``
+is called, at which time it is either finished and moved into place or
+discarded respectively. Write groups cannot be nested, only one can be
+underway at a time on a Repository instance and they must occur within a
+write lock.
+
+Normally the data for each revision will be entirely within a single
+pack but this is not required.
+
+When a pack is finished, it gets a final name based on the md5 of all
+the data written into the pack body file.
+
+The ``pack-names`` file gives the list of all finished non-obsolete
+packs. (This should always be the same as the list of files in the
+``packs/`` directory, but the file is needed for read-only HTTP clients
+that can't easily list directories, and it includes other information.)
+The constraint on the ``pack-names`` list is that every file mentioned
+must exist in the ``packs/`` directory.
+
+In rare cases, when a writer is interrupted, about-to-be-removed packs
+may still be present in the directory but removed from the list.
+
+As well as the list of names, the pack-names file also contains the
+size, in bytes, of each of the four indices. This is used to bootstrap
+bisection search within the indices.
+
+In normal use, one pack will be created for each commit to a repository.
+This would build up to an inefficient number of files over time, so a
+``repack`` operation is available to recombine them, by producing larger
+files containing data on multiple revisions. This can be done manually
+by running ``bzr pack``, and it also may happen automatically when a
+write group is committed.
+
+The repacking strategy used at the moment tries to balance not doing too
+much work during commit with not having too many small files left in the
+repository. The algorithm is roughly this: the total number of
+revisions in the repository is expressed as a decimal number, e.g.
+"532". Then we'll repack until we have five packs containing a hundred
+revisions each, three packs containing ten revisions each, and two packs
+with single revisions. This means that each revision will normally
+initially be created in a single-revision pack, then moved to a
+ten-revision pack, then to a 100-pack, and so on.
+
+As with other repositories, in normal use data is only inserted.
+However, in some circumstances we may want to garbage-collect or prune
+existing data, or reconcile indexes.
+
+..
+ vim: tw=72 ft=rst expandtab
diff --git a/doc/developers/performance-roadmap-rationale.txt b/doc/developers/performance-roadmap-rationale.txt
new file mode 100644
index 0000000..fef2485
--- /dev/null
+++ b/doc/developers/performance-roadmap-rationale.txt
@@ -0,0 +1,116 @@
+What should be in the roadmap?
+==============================
+
+A good roadmap provides a place for contributors to look for tasks, it
+provides users with a sense of when we will fix things that are
+affecting them, and it also allows us all to agree about where we are
+headed. So the roadmap should contain enough things to let all this
+happen.
+
+I think that it needs to contain the analysis work which is required, a
+list of the use cases to be optimised, the disk changes required, and
+the broad sense of the api changes required. It also needs to list the
+inter-dependencies between these things: we should aim for a large
+surface area of 'ready to be worked on' items, that makes it easy to
+improve performance without having to work in lockstep with other
+developers.
+
+Clearly the analysis step is an immediate bottleneck - we cannot tell if
+an optimisation for use case A is a pessimism for use case B until we
+have analysed both A and B. I propose that we complete the analysis of
+say a dozen core use cases end to end during the upcoming sprint in
+London. We should then be able to fork() for much of the detailed design
+work and regroup with disk and api changes shortly thereafter.
+
+I suspect that clarity of layering will make a big difference to
+developer parallelism, so another proposal I have is for us to look at
+the APIs for Branch and Repository in London in the light of what we
+have learnt over the last years.
+
+What should the final system look like, how is it different to what we have today?
+==================================================================================
+
+One of the things I like the most about bzr is its rich library API, and
+I've heard this from numerous other folk. So anything that will remove
+that should be considered a last resort.
+
+Similarly our relatively excellent cross platform support is critical
+for projects that are themselves cross platform, and thats a
+considerable number these days.
+
+And of course, our focus on doing the right thing is what differentiates
+us from some of the other VCS's, so we should be focusing on doing the
+right thing quickly :).
+
+What we have today though has grown organically in response to us
+identifying bottlenecks over several iterations of back end storage,
+branch metadata and the local tree representation. I think we are
+largely past that and able to describe the ideal characteristics of the
+major actors in the system - primarily Tree, Branch, Repository - based
+on what we have learnt.
+
+What use cases should be covered?
+=================================
+
+My list of use cases is probably not complete - its just the ones I
+happen to see a lot :). I think each should be analysed comprehensively
+so we dont need to say 'push over the network' - its implied in the
+scaling analysis that both semantic and file operation latency will be
+considered.
+
+These use cases are ordered by roughly the ease of benchmarking, and the
+frequency of use. This ordering is so that when people are comparing bzr
+they are going to get use cases we have optimised; and so that as we
+speed things up our existing users will have the things they do the most
+optimised.
+
+ * status tree
+ * status subtree
+ * commit
+ * commit to a bound branch
+ * incremental push/pull
+ * log
+ * log path
+ * add
+ * initial push or pull [both to a new repo and an existing repo with
+ different data in it]
+ * diff tree
+ * diff subtree
+
+ * revert tree
+ * revert subtree
+ * merge from a branch
+ * merge from a bundle
+ * annotate
+ * create a bundle against a branch
+ * uncommit
+ * missing
+ * update
+ * cbranch
+
+How is development on the roadmap coordinated?
+==============================================
+
+I think we should hold regular get-togethers (on IRC) to coordinate on
+our progress, because this is a big task and its a lot easier to start
+helping out some area which is having trouble if we have kept in contact
+about each areas progress. This might be weekly or fortnightly or some
+such.
+
+we need a shared space to record the results of the analysis and the
+roadmap as we go forward. Given that we'll need to update these as new
+features are considered, I propose that we use doc/design as a working
+space, and as we analyse use cases we include them in there - including
+the normal review process for each patch. We also need documentation
+about doing performance tuning - not the minutiae, though that is
+needed, but about how to effective choose things to optimise which will
+give the best return on time spent - that is what the roadmap should
+help with, but this looks to be a large project and an overview will be
+of great assistance I think. We want to help everyone that wishes to
+contribute to performance to do so effectively.
+
+Finally, it's important to note that coding is not the only contribution
+- testing, giving feedback on current performance, helping with the
+analysis are all extremely important tasks too and we probably want to
+have clear markers of where that should be done to encourage such
+contributions.
diff --git a/doc/developers/performance-roadmap.txt b/doc/developers/performance-roadmap.txt
new file mode 100644
index 0000000..06ca6d0
--- /dev/null
+++ b/doc/developers/performance-roadmap.txt
@@ -0,0 +1,60 @@
+==========================
+Bazaar Performance Roadmap
+==========================
+
+.. Mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+.. contents::
+.. sectnum::
+
+About the performance roadmap
+#############################
+
+.. include:: performance-roadmap-rationale.txt
+
+.. include:: planned-performance-changes.txt
+
+.. include:: planned-change-integration.txt
+
+Analysis of use cases
+#####################
+
+.. include:: performance-use-case-analysis.txt
+
+Use cases
+#########
+
+.. include:: initial-push-pull.txt
+
+.. include:: incremental-push-pull.txt
+
+.. include:: add.txt
+
+.. include:: commit.txt
+
+.. include:: diff.txt
+
+.. include:: gc.txt
+
+.. include:: revert.txt
+
+.. include:: status.txt
+
+.. include:: annotate.txt
+
+.. include:: merge-scaling.txt
+
+.. include:: bundle-creation.txt
+
+.. include:: uncommit.txt
+
+.. include:: missing.txt
+
+Subsystem designs
+#################
+
+.. include:: directory-fingerprints.txt
diff --git a/doc/developers/performance-use-case-analysis.txt b/doc/developers/performance-use-case-analysis.txt
new file mode 100644
index 0000000..9e6d8c7
--- /dev/null
+++ b/doc/developers/performance-use-case-analysis.txt
@@ -0,0 +1,113 @@
+.. This document describes _how_ to do use case analyses and what we want
+.. to get out of them; for the specific cases see the files referenced by
+.. performance-roadmap.txt
+
+Analysing a specific use case
+=============================
+
+The analysis of a use case needs to provide as outputs:
+ * The functional requirements that the use case has to satisfy.
+ * The file level operations and access patterns that will give the best
+ performance.
+ * A low friction API which will allow the use case to be implemented.
+ * The release of bzr (and thus the supported features) for which the analysis
+ was performed. The feature set of bzr defines the access patterns and data
+ required to implement any use case. So when we add features, their design
+ changes the requirements for the parts of the system they alter, so we need
+ to re-analyse use cases when bzr's feature set changes. If future plans are
+ considered in the analysis with the intention of avoiding rework, these
+ should also be mentioned.
+
+Performing the analysis
+=======================
+
+The analysis needs to be able to define the characteristics of the
+involved disk storage and APIs. That means we need to examine the data
+required for the operation, in what order it is required, on both the
+read and write sides, and how that needs to be presented to be
+consistent with our layering.
+
+As a quick example: 'annotation of a file requires the file id looked up
+from the tree, the basis revision id from the tree, and then the text of
+that fileid-revisionid pair along with the creating revision id
+allocated to each line, and the dotted revision number of each of those
+revision ids.' All three of our key domain objects are involved here,
+but we haven't defined any characteristics of the api or disk facilities
+yet. We could then do that by saying something like 'the file-id lookup
+should degrade gracefully as trees become huge. The tree basis id should
+be constant time. Retrieval of the annotated text should be roughly
+constant for any text of the same size regardless of the number of
+revisions contributing to its content. Mapping of the revision ids to
+dotted revnos could be done as the text is retrieved, but it's completely
+fine to post-process the annotated text to obtain dotted-revnos.'
+
+What factors should be considered?
+==================================
+
+Obviously, those that will make for an extremely fast system :). There
+are many possible factors, but the ones I think are most interesting to
+design with are:
+
+- baseline overhead:
+
+ - The time to get bzr ready to begin the use case.
+
+- scaling: how does performance change when any of the follow aspects
+ of the system are ratcheted massively up or down:
+
+ - number of files/dirs/symlinks/subtrees in a tree (both working and
+ revision trees)
+ - size of any particular file
+ - number of elements within a single directory
+ - length of symlinks
+ - number of changes to any file over time
+ (subordinately also the number of merges of the file)
+ - number of commits in the ancestry of a branch
+ (subordinately also the number of merges)
+ - number of revisions in a repository
+ - number of fileids in a repository
+ - number of ghosts in a given graph (revision or per-file)
+ - number of branches in a repository
+ - number of concurrent readers for a tree/branch/repository
+ - number of concurrent writers for objects that support that.
+ - latency to perform file operations (e.g. slow disks, network file systems,
+ our VFS layer and FTP/SFTP/etc)
+ - bandwidth to the disk storage
+ - latency to perform semantic operations (hpss specific)
+ - bandwidth when performing semantic operations.
+
+- locality of reference: If an operation requires data that is located
+ within a small region at any point, we often get better performance
+ than with an implementation of the same operation that requires the
+ same amount of data but with a lower locality of reference. It's
+ fairly tricky to add locality of reference after the fact, so I think
+ its worth considering up front.
+
+Using these factors, to the annotate example we can add that its
+reasonable to do two 'semantic' round trips to the local tree, one to
+the branch object, and two to the repository. In file-operation level
+measurements, in an ideal world there would be no more than one round
+trip for each semantic operation. What there must not be is one round
+trip per revision involved in the revisionid->dotted number mapping, nor
+per each revision id attributed to a line in the text.
+
+Not all the items mentioned above are created equal. The analysis should
+include the parameters considered and the common case values for each - the
+optimisation should be around the common cases not around the exceptions.
+
+For instance, we have a smart server now; file level operations are relatively
+low latency and we should use that as the common case. At this point we intend
+to preserve the performance of the dumb protocol networking, but focus on
+improving network performance via the smart server and thus escape the
+file-level operation latency considerations.
+
+Many performance problems only become visible when changing the scaling knobs
+upwards to large trees. On small trees it's our baseline performance that drives
+incremental improvements; on large trees it's the amount of processing per item
+that drives performance. A significant goal therefore is to keep the amount of
+data to be processed under control. Ideally we can scale in a sublinear fashion
+for all operations, but we MUST NOT scale even linearly for operations that
+invoke a latency multiplier. For example, reading a file on disk requires
+finding the inode for the file, then the block with the data and returning the
+contents. Due to directory grouping logic we pay a massive price to read files
+if we do not group the reads of files within the same directory.
diff --git a/doc/developers/performance.dot b/doc/developers/performance.dot
new file mode 100644
index 0000000..96e9620
--- /dev/null
+++ b/doc/developers/performance.dot
@@ -0,0 +1,137 @@
+/* ESTIMATES ARE VERY ROUGH APPROXIMATIONS */
+strict digraph performance {
+ rankdir=LR
+ /* completed node list */
+ node[color="green"];
+ add_analysis[label="Work required analysis for add"];
+ annotate_analysis[label="Work required analysis for annotate"];
+ branch_analysis[label="Work required analysis for branch"];
+ bundle_analysis[label="Work required analysis for creating a bundle"];
+ commit_analysis[label="Work required analysis for commit"];
+ fetch_analysis[label="Work required analysis for push/pull"];
+ gc_analysis[label="Work required analysis for gc"];
+ missing_analysis[label="Work required analysis for missing"];
+ revert_analysis[label="Work required analysis for revert"];
+ revert_path_analysis[label="Work required analysis for revert of selected paths"];
+ status_analysis[label="Work required analysis for status"];
+ uncommit_analysis[label="Work required analysis for uncommit"];
+ wt_disk_order[label="Working Tree disk ordering\n6-8 weeks"];
+ iter_merge[label="iter_changes based merge\n2 days"];
+ diff_analysis[label="Work required analysis for diff"];
+
+ /* uncompleted node list - add new tasks here */
+ node[color="blue"];
+ log_analysis[label="Work required analysis for log"];
+ log_path_analysis[label="Work required analysis for log of selected paths."];
+ diff_path_analysis[label="Work required analysis for diff of selected paths"];
+ merge_analysis[label="Work required analysis for merge"];
+ update_analysis[label="Work required analysis for update"];
+ cbranch_analysis[label="Work required analysis for cbranch"];
+
+ add_api_stack[label="Targeted API stack for add"];
+ branch_api_stack[label="Targeted API stack for branch"];
+ bundle_api_stack[label="Targeted API stack for creating a bundle"];
+ annotate_api_stack[label="Targeted API stack for annotate"];
+ status_api_stack[label="Targeted API stack for status"];
+ commit_api_stack[label="Targeted API stack for commit"];
+ fetch_api_stack[label="Targeted API stack for push/pull"];
+ log_api_stack[label="Targeted API stack for log"];
+ log_path_api_stack[label="Targeted API stack for log of selected paths."];
+ diff_api_stack[label="Targeted API stack for diff"];
+ gc_api_stack[label="Targeted API stack for gc"];
+ revert_api_stack[label="Targeted API stack for revert"];
+ revert_path_api_stack[label="Targeted API stack for revert of selected paths"];
+ merge_api_stack[label="Targeted API stack for merge"];
+ uncommit_api_stack[label="Targeted API stack for uncommit"];
+ missing_api_stack[label="Targeted API stack for missing"];
+ update_api_stack[label="Targeted API stack for update"];
+ cbranch_api_stack[label="Targeted API stack for cbranch"];
+
+ data_collation[label="Stream API for inserting/obtaining revision data.\n1 month"];
+ repository_stacking[label="Repository stacking API\n2 months"];
+ new_container[label="New container format\n2 weeks"]
+ xdelta[label="Xdelta sanity/learning\n2 weeks"];
+ xdelta_imp[label="Xdelta implementation\n1 week"];
+ q_splitting[label="Question radix directory splitting\n2 weeks"];
+ i_splitting[label="Inventory storage changed to answer what-changed quickly\n6-8 weeks"]
+ per_file_graph[label="Provide an API for per-file\n graph data rather than\n physical storage coupled knits api.\n1 days"];
+ deprecate_versionedfile_api[label="Deprecate the public API for access to physical knit storage."];
+ anno_cache[label="Annotations become a cache:\n logically separate data\n2 weeks"]
+ anno_regen[label="Annotation regeneration\n"];
+ anno_kinds[label="Different styles of annotation"];
+ memory_copies[label="Stop requiring full memory copies of files"];
+ repo_disk_order[label="Repository disk ordering\n1 month"];
+ pack_repository[label="Pack based repository format"];
+ graph_api[label="Network-efficient revision-graph API\n3 week"];
+ validators[label="Build new validators for revisions and trees."];
+
+ /* under discussion/optional */
+ node[color="yellow"];
+ hash_names[label="Use hashes as names for some objects\n(to reduce tracking metadata and ease interoperability."];
+ gdfo_api[label="GDFO API\n1 day"];
+ gdfo_cache[label="GDFO Cache\n1 week"];
+ gdfo_usage[label="GDFO Usage\n3 days"];
+
+ /* dependencies */
+ gc_analysis -> gc_api_stack;
+ gdfo_api -> gdfo_cache;
+ gdfo_api -> gdfo_usage;
+ xdelta -> xdelta_imp;
+ q_splitting -> i_splitting;
+ per_file_graph -> deprecate_versionedfile_api;
+ anno_regen -> anno_kinds;
+ anno_cache -> anno_regen;
+ add_analysis -> add_api_stack;
+ annotate_analysis -> annotate_api_stack -> anno_cache;
+ annotate_api_stack -> per_file_graph -> graph_api;
+ annotate_api_stack -> memory_copies;
+ annotate_api_stack -> hash_names;
+ branch_analysis -> branch_api_stack -> repository_stacking;
+ branch_api_stack -> memory_copies;
+ bundle_analysis -> bundle_api_stack -> data_collation;
+ bundle_api_stack -> repository_stacking;
+ bundle_api_stack -> validators;
+ bundle_api_stack -> graph_api;
+ bundle_api_stack -> memory_copies;
+ bundle_api_stack -> new_container;
+ bundle_analysis -> hash_names;
+ cbranch_analysis -> cbranch_api_stack;
+ commit_analysis -> commit_api_stack -> data_collation;
+ commit_api_stack -> per_file_graph;
+ commit_api_stack -> validators;
+ commit_api_stack -> memory_copies;
+ commit_api_stack -> hash_names;
+ diff_analysis -> diff_api_stack;
+ diff_api_stack -> memory_copies;
+ diff_path_analysis -> diff_api_stack -> i_splitting;
+ diff_api_stack -> hash_names;
+ fetch_analysis -> fetch_api_stack -> data_collation;
+ fetch_api_stack -> repository_stacking;
+ fetch_api_stack -> graph_api;
+ fetch_api_stack -> memory_copies;
+ fetch_api_stack -> hash_names;
+ repository_stacking -> graph_api;
+ hash_names -> i_splitting;
+ log_analysis -> log_api_stack -> i_splitting;
+ log_path_analysis -> log_path_api_stack;
+ log_path_api_stack -> per_file_graph;
+ merge_analysis -> merge_api_stack -> iter_merge -> i_splitting;
+ merge_api_stack -> memory_copies;
+ missing_analysis -> missing_api_stack -> repository_stacking;
+ missing_api_stack -> graph_api;
+ new_container -> pack_repository;
+ pack_repository -> xdelta_imp;
+ pack_repository -> repo_disk_order;
+ per_file_graph -> hash_names;
+ repository_stacking -> pack_repository;
+ repository_stacking -> new_container;
+ revert_analysis -> revert_api_stack -> data_collation;
+ revert_path_analysis -> revert_path_api_stack;
+ revert_api_stack -> memory_copies;
+ status_analysis -> status_api_stack;
+ status_api_stack -> memory_copies;
+ uncommit_analysis -> uncommit_api_stack -> data_collation;
+ uncommit_api_stack -> graph_api;
+ update_analysis -> update_api_stack;
+ update_api_stack -> memory_copies;
+}
diff --git a/doc/developers/planned-change-integration.txt b/doc/developers/planned-change-integration.txt
new file mode 100644
index 0000000..1109110
--- /dev/null
+++ b/doc/developers/planned-change-integration.txt
@@ -0,0 +1,143 @@
+Integration of performance changes
+==================================
+
+To deliver a version of bzr with all our planned changes will require
+significant integration work. Minimally each change needs to integrate with
+some aspect of the bzr version it's merged into, but in reality many of these
+changes while conceptually independent will in fact have to integrate with the
+other changes we have planned before can have a completed system.
+
+Additionally changes that alter disk formats are inherently more tricky to
+integrate because we will often need to alter apis throughout the code base to
+expose the increased or reduced model of the preferred disk format.
+
+You can generate a graph ``performance.png`` in the source tree from
+Graphviz "dot" file ``performance.dot``. This graphs out the dependencies
+to let us make accurate assessments of the changes needed in terms of code
+and API, hopefully minimising the number of different integration steps we
+have to take, while giving us a broad surface area for development. It's
+based on a summary in the next section of this document of the planned
+changes with their expected collaborators and dependencies. Where a
+command is listed, the expectation is that all uses of that command -
+local, remote, dumb transport and smart transport are being addressed
+together.
+
+
+The following provides a summary of the planned changes and their expected
+collaborators within the code base, along with an estimate of whether they are
+likely to require changes to their collaborators to be considered 'finished'.
+
+ * Use case target APIs: Each of these is likely to alter the Tree interface.
+ Some few of them focus on Branch and will alter Branch and Repository
+ accordingly. As they are targeted APIs we can deep changes all the way down
+ the stack to the underlying representation to make it all fit well.
+ Presenting a top level API for many things will be possible now as long as
+ the exposed data is audited for things we plan to make optional, or remove:
+ Such things cannot be present in the final API. Writing these APIs now will
+ provide strong feedback to the design process for those things which are
+ considered optional or removable, so these APIs should be implemented
+ before removing or making optional existing data.
+
+ * Deprecating versioned files as a supported API: This collaborates with the
+ Repository API but can probably be done by adding a replacement API for
+ places where the versioned-file api is used. We may well want to keep a
+ concept of 'a file over time' or 'inventories over time', so the existing
+ repository model of exposing versioned file objects may be ok; what we need
+ to ensure we do is remove the places in the code base where you create or
+ remove or otherwise describe manipulation of the storage by knit rather than
+ talking at the level of file ids and revision ids. The current
+ versioned-file API would be a burden for implementors of a blob based
+ repository format, so the removal of callers, and deprecation of those parts
+ of the API should be done before creating a blob based repository format.
+
+ * Creating a revision validator: Revision validators may depend on storage
+ layer changes to inventories so while we can create a revision validator
+ API, we cannot create the final one until we have the inventory structural
+ changes completed.
+
+ * Annotation caching API: This API is a prerequisite for new repository
+ formats. If written after they are introduced we may find that the
+ repository is lacking in functionality, so the API should be implemented
+ first.
+
+ * _iter_changes based merging: If the current _iter_changes_ API is
+ insufficient, we should know about that before designing the disk format for
+ generating fast _iter_changes_ output.
+
+ * Network-efficient revision graph API: This influences what questions we will
+ want to ask a local repository very quickly; as such it's a driver for the
+ new repository format and should be in place first if possible. It's probably
+ not sufficiently different to local operations to make this a hard ordering
+ though.
+
+ * Working tree disk ordering: Knowing the expected order for disk operations
+ may influence the needed use case specific APIs, so having a solid
+ understanding of what is optimal - and why - and whether it is pessimal on
+ non-Linux-kernel platforms is rather important.
+
+ * Be able to version files greater than memory in size: This cannot be
+ achieved until all parts of the library which deal with user files are able
+ to provide access to files larger than memory. Many strategies can be
+ considered for this - such as temporary files on disk, memory mapping etc.
+ We should have enough of a design laid out that developers of repository and
+ tree logic are able to start exposing apis, and considering requirements
+ related to them, to let this happen.
+
+ * Per-file graph access API: This should be implemented on top of or as part
+ of the newer API for accessing data about a file over time. It can be a
+ separate step easily; but as it's in the same area of the library should not
+ be done in parallel.
+
+ * Repository stacking API: The key dependency/change required for this is that
+ repositories must individually be happy with having partial data - e.g. many
+ ghosts. However the way the API needs to be used should be driven from the
+ command layer in, because it's unclear at the moment what will work best.
+
+ * Revision stream API: This API will become clear as we streamline commands.
+ On the data insertion side commit will want to generate new data. The
+ commands pull, bundle, merge, push, possibly uncommit will want to copy
+ existing data in a streaming fashion.
+
+ * New container format: It's hard to tell what the right way to structure the
+ layering is. Probably having smooth layering down to the point that code
+ wants to operate on the containers directly will make this more clear. As
+ bundles will become a read-only branch & repository, the smart server wants
+ streaming-containers, and we are planning a pack based repository, it
+ appears that we will have three different direct container users. However,
+ the bundle user may in fact be fake - because it really is a repository.
+
+ * Separation of annotation cache: Making the disk changes to achieve this
+ depends on the new API being created. Bundles probably want to be
+ annotation-free, so they are a form of implementation of this and will need
+ the on-demand annotation facility.
+
+ * Repository operation disk ordering: Dramatically changing the ordering of
+ disk operations requires a new repository format. We have most of the
+ analysis done to be able to specify the desired ordering, so it should be
+ possible to write such a format now based on the container logic, but
+ without any of the inventory representation or delta representation changes.
+ This would for instance involve pack combining ordering the existing diffs
+ in reverse order.
+
+ * Inventory representation: This has a dependency on what data is
+ dropped from the core and what is kept. Without those changes being known we
+ can implement a new representation, but it won't be a final one. One of the
+ services the new inventory representation is expected to deliver is one of
+ validators for subtrees -- a means of comparing just subtrees of two
+ inventories without comparing all the data within that subtree.
+
+ * Delta storage optimisation: This has a strict dependency on a new repository
+ format. Optimisation takes many forms - we probably cannot complete the
+ desired optimisations under knits though we could use xdelta within a
+ knit-variation.
+
+ * Greatest distance from origin cache: The potential users of this exist
+ today, it is likely able to be implemented immediately, but we are not sure
+ that its needed anymore, so it is being shelved.
+
+ * Removing derivable data: It's very hard to do this while the derived data is
+ exposed in API's but not used by commands. Implemented the targeted API's
+ for our core use cases should allow use to remove accidental use of derived
+ data, making only explicit uses of it visible, and isolating the impact of
+ removing it : allowing us to experiment sensibly. This covers both dropping
+ the per-file merge graph and the hash-based-names proposals.
diff --git a/doc/developers/planned-performance-changes.txt b/doc/developers/planned-performance-changes.txt
new file mode 100644
index 0000000..aa8ef35
--- /dev/null
+++ b/doc/developers/planned-performance-changes.txt
@@ -0,0 +1,167 @@
+Planned changes to the bzr core
+===============================
+
+Delivering the best possible performance requires changing the bzr core design
+from that present in 0.16. Some of these changes are incremental and can be
+done with no impact on disk format. Many of them however do require changes to
+the disk format, and these can be broken into two sets of changes, those which
+are sufficiently close to the model bzr uses today to interoperate with the
+0.16 disk formats, and those that are not able to interoperate with the 0.16
+disk formats - specifically some planned changes may result in data which
+cannot be exported to bzr 0.16's disk formats and then imported back to the new
+format without losing critical information. If/when this takes place it will be
+essentially a migration for users to switch from their bzr 0.16 repository to a
+bzr that supports them. We plan to batch all such changes into one large
+'experimental' repository format, which will be complete stable and usable
+before we migrate it to become a supported format. Getting new versions of bzr
+in widespread use at that time will be very important, otherwise the user base
+may be split in two - users that have upgraded and users that have not.
+
+The following changes are grouped according to their compatability impact:
+library only, disk format but interoperable, disk format interoperability
+unknown, and disk format, not interoperable.
+
+Library changes
+---------------
+
+These changes will change bzrlib's API but will not affect the disk format and
+thus do not pose a significant migration issue.
+
+ * For our 20 core use cases, we plan to add targeted API's to bzrlib that are
+ repository-representation agnostic. These will instead reflect the shape of
+ data access most optimal for that case.
+
+ * Deprecate 'versioned files' as a library concept. Instead of asking for
+ information about a file-over-time as a special case, we will move to an API
+ that assumes less coupling between the historical information and the
+ ability to obtain texts/deltas etc. Specifically, we need to remove all
+ API's that act in terms of on disk representation except those within a
+ given repository implementation.
+
+ * Create a validator for revisions that is more amenable to use by other parts
+ of the code base than just the gpg signing facility. This can be done today
+ without changing disk, possibly with a performance hit until the disk
+ formats match the validatory logic. It will be hard to tell if we have the
+ right routine for that until all the disk changes are complete, so while
+ this is a library only change, it's likely one that will be delayed to near
+ the end of the process.
+
+ * Add an explicit API for managing cached annotations. While annotations are
+ considered a cache this is not exposed in such a way that cache operations
+ like 'drop the cache' can be performed. On current disk formats the cache is
+ mandatory, but an API to manage would allow refreshing of the cache (e.g.
+ after ghosts are filled in during baz conversions).
+
+ * Use the _iter_changes API to perform merges. This is a small change that may
+ remove the need to use inventories in merge, making a dramatic difference to
+ merge performance once the tree shape comparison optimisations are
+ implemented.
+
+ * Create a network-efficient revision graph API. This is the logic at the
+ start of push and pull operations, which currently scales O(graph size).
+ Fixing the scaling can be done, but there are tradeoffs to latency and
+ performance to consider, making it a little tricky to get right.
+
+ * Working tree disk operation ordering. We plan to change the order in which
+ some operations are done (specifically TreeTransform ones) to improve
+ performance. There is already a 66% performance boost in that area going
+ through review.
+
+ * Stop requiring full memory copies of files. Currently bzr requires that it
+ can hold 3 copies of any file it's versioning in memory. Solving this is
+ tricky, particularly without performance regressions on small files, but
+ without solving it versioning of .iso and other large objects will continue
+ to be extremely painful.
+
+ * Add an API for per-file graph access that alllows incremental access and is
+ suitable for on-demand generation if desired.
+
+ * Repository stacking API. Allowing multiple databases to be stacked to give a
+ single 'repository' will allow implementation of some long desired features
+ like history horizons, and bundle usage where the bundle is not added to the
+ local repository just to examine its contents.
+
+ * Revision data manipulation API. We need a single streaming API for adding
+ data to or getting it from a repository. This will need to allow hints such
+ as 'optimise for size', or 'optimise for fast-addition' to meet the various
+ users planned, but it is a core part of the library today, and it's not
+ sufficiently clean to let us simplify/remove a lot of related code today.
+
+Interoperable disk changes
+--------------------------
+
+ * New container format to allow single-file description of multiple named
+ objects. This will provide the basis for transmission of revisions over the
+ network, the new bundle format, and possibly a new repository format as
+ well. [Core implemented]
+
+ * Separate the annotation cache from the storage of actual file texts and make
+ the annotation style, and when to do it, configurable. This will reduce data
+ sent over the wire when repositories have had 'needs-annotations' turned
+ off, which very large trees may choose to do - generating just-in-time
+ annotations may be desirable for those trees (even when performing
+ annotation based merges).
+
+ * Repository disk operation ordering. The order that tasks access data within
+ the repository and the layout of the data should be harmonised. This will
+ require disk format changes but does not inherently alter the model, so it's
+ straight forward to export from a repository that has been optimised in this
+ way to a 0.16 based repository.
+
+ * Inventory representation. An inventory is a logical description of the shape
+ of a version controlled tree. Currently we operate on the whole inventory as
+ a tree broken down per directory, but we store it as a flat file. This scale
+ very poorly as even a minor change between inventories requires us to scan
+ the entire file, and in large trees this is many megabytes of data to
+ consider. We are investigating the exact form, but the intent is to change
+ the serialisation of inventories so that comparing two inventories can be
+ done in some smaller time - e.g. O(log N) scaling. Whatever form this takes,
+ a repository that can export it directly will be able to perform operations
+ between two historical trees much more efficiently than the current
+ repositories.
+
+ * Greatest distance from origin cache. This is a possible change to introduce,
+ but it may be unnecessary - listed here for completeness till it has been
+ established as [un]needed.
+
+Possibly non-interoperable disk changes
+---------------------------------------
+
+ * Removing of derivable data from the core of bzr. Much of the data that bzr
+ stores is derivable from the users source files. For instance the
+ annotations that record who introduced a line. Given the full history for a
+ repository we can recreate that at any time. We want to remove the
+ dependence of the core of bzr on any data that is derivable, because doing
+ this will give us the freedom to:
+
+ * Improve the derivation algorithm over time.
+ * Deal with bugs in the derivation algorithms without having 'corrupt
+ repositories' or such things.
+
+ However, some of the data that is technically derived, like the per-file
+ merge graph, is both considered core, and can be generated differently when
+ certain circumstances arive, by bzr 0.16. Any change to the 'core' status of
+ that data will discard data that cannot be recreated and thus lead to the
+ inability to export from a format where that is derived data to bzr 0.16's
+ formats without errors occuring in those circumstances. Some of the data
+ that may be considered for this includes:
+
+ * Per file merge graphs
+ * Annotations
+
+Non-interoperable disk changes
+------------------------------
+
+ * Drop the per-file merge graph 'cache' currently held in the FILE-ID.kndx
+ files. A specific case of removing derivable data, this may allow smaller
+ inventory metadata and also make it easier to allow two different trees (in
+ terms of last-change made, e.g. if one is a working tree) to be compared
+ using a hash-tree style approach.
+
+ * Use hash based names for some objects in the bzr database. Because it would force
+ total-knowledge-of-history on the graph revision objects will not be namable
+ via hash's and neither will revisio signatures. Other than that though we
+ can in principle use hash's e.g. SHA1 for everything else. There are many
+ unanswered questions about hash based naming related to locality of
+ reference impacts, which need to be answered before this becomes a definite
+ item.
diff --git a/doc/developers/plans.txt b/doc/developers/plans.txt
new file mode 100644
index 0000000..b86a753
--- /dev/null
+++ b/doc/developers/plans.txt
@@ -0,0 +1,11 @@
+Plans
+=====
+
+.. toctree::
+ :maxdepth: 1
+
+ Performance roadmap <performance-roadmap>
+ new-config-rationale
+ tortoise-strategy
+ improved_chk_index
+ nested-trees
diff --git a/doc/developers/plugin-api.txt b/doc/developers/plugin-api.txt
new file mode 100644
index 0000000..8915487
--- /dev/null
+++ b/doc/developers/plugin-api.txt
@@ -0,0 +1,262 @@
+==========
+Plugin API
+==========
+
+
+
+:Date: 2009-01-23
+
+.. contents::
+
+Introduction
+============
+
+bzrlib has a very flexible internal structure allowing plugins for many
+operations. Plugins can add commands, new storage formats, diff and merge
+features and more. This document provides an overview of the API and
+conventions for plugin authors.
+
+If you're writing a plugin and have questions not addressed by this
+document, please ask us.
+
+See also
+--------
+
+ * `Bazaar Developer Documentation Catalog <../index.html>`_.
+ * `Bazaar Plugins Guide <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_ for
+ more suggestions about particular APIs.
+
+
+Structure of a plugin
+=====================
+
+Plugins are Python modules under ``bzrlib.plugins``. They can be installed
+either into the PYTHONPATH in that location, or in ~/.bazaar/plugins.
+
+Plugins should have a setup.py.
+
+As for other Python modules, the name of the directory must match the
+expected name of the plugin.
+
+
+Plugin metadata before installation
+===================================
+
+Plugins can export a summary of what they provide, and what versions of bzrlib
+they are compatible with. This allows tools to be written to work with plugins,
+such as to generate a directory of plugins, or install them via a
+symlink/checkout to ~/.bazaar/plugins.
+
+This interface allows bzr to interrogate a plugin without actually loading
+it. This is useful because loading a plugin may have side effects such
+as registering or overriding commands, or the plugin may raise an error,
+if for example a prerequisite is not present.
+
+
+Metadata protocol
+-----------------
+
+A plugin that supports the bzr plugin metadata protocol will do two
+things. Firstly, the ``setup.py`` for the plugin will guard the call to
+``setup()``::
+
+ if __name__ == 'main':
+ setup(...)
+
+Secondly, the setup module will have one or more of the following variables
+present at module scope. Any variables that are missing will be given the
+defaults from the table. An example of every variable is provided after
+the full list.
+
++------------------------+---------+----------------------------------------+
+| Variable | Default | Definition |
++========================+=========+========================================+
+| bzr_plugin_name | None | The name the plugin package should be |
+| | | given on disk. The plugin is then |
+| | | available to python at |
+| | | bzrlib.plugins.NAME |
++------------------------+---------+----------------------------------------+
+| bzr_commands | [] | A list of the commands that the plugin |
+| | | provides. Commands that already exist |
+| | | in bzr and are decorated by the plugin |
+| | | do not need to be listed (but it is not|
+| | | harmful if you do list them). |
++------------------------+---------+----------------------------------------+
+| bzr_plugin_version | None | A version_info 5-tuple with the plugins|
+| | | version. |
++------------------------+---------+----------------------------------------+
+| bzr_minimum_version | None | A version_info 3-tuple for comparison |
+| | | with the bzrlib minimum and current |
+| | | version, for determining likely |
+| | | compatibility. |
++------------------------+---------+----------------------------------------+
+| bzr_maximum_version | None | A version_info 3-tuple like |
+| | | bzr_minimum_version but checking the |
+| | | upper limits supported. |
++------------------------+---------+----------------------------------------+
+| bzr_control_formats | {} | A dictionary of descriptions of version|
+| | | control directories. See |
+| | | `Control Formats` below. |
++------------------------+---------+----------------------------------------+
+| bzr_checkout_formats | {} | A dictionary of tree_format_string -> |
+| | | human description strings, for tree |
+| | | formats that drop into the |
+| | | ``.bzr/checkout`` metadir system. |
++------------------------+---------+----------------------------------------+
+| bzr_branch_formats | {} | As bzr_checkout_formats but for |
+| | | branches. |
++------------------------+---------+----------------------------------------+
+| bzr_repository_formats | {} | As bzr_checkout_formats but for |
+| | | repositories. |
++------------------------+---------+----------------------------------------+
+| bzr_transports | [] | URL prefixes for which this plugin |
+| | | will register transports. |
++------------------------+---------+----------------------------------------+
+
+Control Formats
+---------------
+
+Because disk format detection for formats that bzr does not understand at
+all can be useful, we allow a declarative description of the shape of a
+control directory. Each description has a name for showing to users, and a
+dictonary of relative paths, and the content needed at each path. Paths
+that end in '/' are required to be directories and the value for that key
+is ignored. Other paths are required to be regular files, and the value
+for that key is either None, in which case the file is statted but the
+content is ignored, or a literal string which is compared against for
+the content of the file. Thus::
+
+ # (look for a .hg directory)
+ bzr_control_formats = {"Mercurial":{'.hg/': None}}
+
+ # (look for a file called .svn/format with contents 4\n).
+ bzr_control_formats = {"Subversion":{'.svn/format': '4\n'}}
+
+
+Example
+-------
+
+An example setup.py follows::
+
+ #!/usr/bin/env python2.4
+ from distutils.core import setup
+
+ bzr_plugin_name = 'demo'
+ bzr_commands = [
+ 'new-command',
+ ]
+
+ bzr_branch_formats = {
+ "Branch label on disk\n":"demo branch",
+ }
+
+ bzr_control_formats = {"Subversion":{'.svn/format': '4\n'}}
+
+ bzr_transports = ["hg+ssh://"]
+
+ bzr_plugin_version = (1, 3, 0, 'dev', 0)
+ bzr_minimum_version = (1, 0, 0)
+
+ if __name__ == 'main':
+ setup(name="Demo",
+ version="1.3.0dev0",
+ description="Demo plugin for plugin metadata.",
+ author="Canonical Ltd",
+ author_email="bazaar@lists.canonical.com",
+ license = "GNU GPL v2",
+ url="https://launchpad.net/bzr-demo",
+ packages=['bzrlib.plugins.demo',
+ 'bzrlib.plugins.demo.tests',
+ ],
+ package_dir={'bzrlib.plugins.demo': '.'})
+
+
+Plugin metadata after installation
+==================================
+
+After a plugin has been installed, metadata can be more easily obtained by
+looking inside the module object -- in other words, for variables defined
+in the plugin's ``__init__.py``.
+
+Help and documentation
+----------------------
+
+The module docstring is used as the plugin description shown by ``bzr
+plugins``. As with all Python docstrings, the first line should be a
+short complete sentence summarizing the plugin. The full docstring is
+shown by ``bzr help PLUGIN_NAME``.
+
+This is a user-visible docstring so should be prefixed with ``__doc__ =``
+to ensure help works under ``python -OO`` with docstrings stripped.
+
+API version
+-----------
+
+Plugins can and should declare that they depend on a particular version of
+bzrlib like so::
+
+ from bzrlib.api import require_api
+
+ require_api(bzrlib, (1, 11, 0))
+
+Please see `API versioning <api-versioning.html>`_ for more details on the API
+metadata protocol used by bzrlib.
+
+Plugin version
+--------------
+
+The plugin should expose a version tuple to describe its own version.
+Some plugins use a version number that corresponds to the version of bzr
+they're released against, but you can use whatever you want. For example::
+
+ version_info = (1, 10, 0)
+
+
+Detecting whether code's being loaded as a plugin
+-------------------------------------------------
+
+You may have a Python module that can be used as a bzr plugin and also in
+other places. To detect whether the module is being loaded by bzr, use
+something like this::
+
+ if __name__ == 'bzrlib.plugins.loggerhead':
+ # register with bzrlib...
+
+
+Plugin performance
+==================
+
+Plugins should avoid doing work or loading code from the plugin or
+external libraries, if they're just installed but not actually active,
+because this slows down every invocation of bzr. The bzrlib APIs
+generally allow the plugin to 'lazily' register methods to invoke if a
+particular disk format or seen or a particular command is run.
+
+
+Plugin registrations
+====================
+
+The plugin ``__init__.py`` runs when the plugin is loaded during bzr
+startup. Generally the plugin won't want to actually do anything at this
+time other than register or override functions to be called later.
+
+The plugin can import bzrlib and call any function.
+Some interesting APIs are described in `Bazaar Plugins Guide <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_.
+
+
+Publishing your plugin
+======================
+
+When your plugin is basically working you might like to share it with
+other people. Here are some steps to consider:
+
+ * make a project on Launchpad.net like
+ <https://launchpad.net/bzr-fastimport>
+ and publish the branches or tarballs there
+
+ * include the plugin in <http://wiki.bazaar.canonical.com/BzrPlugins>
+
+ * post about it to the ``bazaar-announce`` list at ``lists.canonical.com``
+
+..
+ vim: ft=rst tw=74 ai shiftwidth=4
diff --git a/doc/developers/ppa.txt b/doc/developers/ppa.txt
new file mode 100644
index 0000000..bca2cf6
--- /dev/null
+++ b/doc/developers/ppa.txt
@@ -0,0 +1,367 @@
+Managing the Bazaar PPA
+=======================
+
+See also: `Bazaar Developer Document Catalog <index.html>`_.
+
+
+Background
+----------
+
+We build Ubuntu ``.deb`` packages for Bazaar as an important part of the
+release process. These packages are hosted in a few `Personal Package
+Archives (PPA)`__ on Launchpad.
+
+ __ https://help.launchpad.net/PPAQuickStart
+
+As of January 2011, there are the following PPAs:
+
+<https://launchpad.net/~bzr/+archive/ppa>
+ Final released versions and updates.
+ Most users who want updates to bzr should add this.
+
+<https://launchpad.net/~bzr/+archive/proposed>
+ Proposed uploads to move into ~bzr/ppa, awaiting testing.
+
+<https://launchpad.net/~bzr/+archive/obsolete>
+ A preserved copy of the final version of packages from ~bzr/ppa for
+ obsolete Ubuntu series.
+
+<https://launchpad.net/~bzr/+archive/beta>
+ Beta releases.
+
+<https://launchpad.net/~bzr/+archive/beta-obsolete>
+ A preserved copy of the final version of packages from
+ ~bzr/beta for obsolete Ubuntu series.
+
+<https://launchpad.net/~bzr/+archive/daily>
+ Automatic nightly builds from trunk.
+
+We build a distinct package for each distrorelease.
+If you upload a release-specific version, you should add a suffix to the
+package version, e.g. ``1.3-1~bazaar1~dapper1``.
+
+Dapper uses the ``python-support`` framework and later distributions use
+``python-central``. This has little effect on everyday packaging but does
+mean that some of the control files are quite different.
+
+Beta releases of bzr and plugins are uploaded into the beta PPA.
+
+Final release versions are first uploaded into the proposed PPA, which
+serves as a staging area to allow for new packages to be tested, and also
+so that a complete set of Bazaar core and plugin updated versions can be
+prepared together, when negotiating an API version transition.
+
+Once ready, packages can be copied from the proposed PPA to the main PPA
+using the lp-promote-ppa script found within the hydrazine project. This
+procedure reduces the risk of broken packages or dependencies between
+packages in the main PPA from which many people get bzr updates.
+
+The packaging information is kept in branches of bzr on Launchpad, named
+like
+<https://code.launchpad.net/~bzr/ubuntu/hardy/bzr/bzr-ppa>.
+or
+<lp:~bzr/ubuntu/hardy/bzr/bzr-ppa>. These branches are intended to be used
+with the ``bzr-builddeb`` plugin.
+
+The page <http://wiki.bazaar.canonical.com/PpaPackagingBranches> is a
+reference to where the PPA packaging branches for each of the source
+packages in the ``~bzr`` PPAs may be found.
+
+
+Supported releases
+------------------
+
+We build packages for every supported Ubuntu release
+<https://wiki.ubuntu.com/Releases>. Packages need no longer be updated
+when the release passes end-of-life because all users should
+have upgraded by then.
+
+As of August 2010, the following releases are supported:
+
+* Maverick
+* Lucid LTS
+* Karmic
+* Jaunty (support ends October 2010)
+* Hardy LTS
+* Dapper LTS (supported but no longer updated for new releases)
+
+The ``rmadison bzr`` command will gives you an up-to-date summary
+of which bzr releases are current in each Ubuntu release.
+
+Preconditions
+-------------
+
+* You must have a Launchpad account and be a member of the team
+ that owns these PPAs (``~bzr``).
+
+* You must have a GPG key registered to your Launchpad account.
+
+On reasonably recent versions of Ubuntu you no longer need special dput
+configuration, because you can just say ::
+
+ dput ppa:bzr/proposed source.changes
+
+
+However, you may still want to add these lines to ``~/.dput.cf`` prevent
+inadvertently attempting to upload into Ubuntu or Debian, which will
+give a somewhat unclear error::
+
+ [DEFAULT]
+ default_host_main = notspecified
+
+* You need a Ubuntu (or probably Debian) machine, and ::
+
+ sudo apt-get install build-essential devscripts dput quilt patch libcrypt-ssleay-perl debhelper cdbs python-docutils
+
+ Please update this document if you encounter unmet dependencies or find a
+ shorter way to express them.
+
+* You will also want to have the `bzr-builddeb`_ plugin installed.
+
+.. _`bzr-builddeb`: http://launchpad.net/bzr-builddeb
+
+
+Packaging Bazaar
+----------------
+
+Overview of packaging with builddeb
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+* First update the oldest supported branch, using ``bzr merge-upstream``.
+
+* Run ``bzr builddeb -S -- -sa`` to build a source package, then put
+ that into the ppa.
+
+ (``-S`` says to make a source-only upload, which is
+ required for Launchpad's builders. ``-sa`` says to include the
+ ``.orig.tgz`` even if this doesn't seem to be the first upload for an
+ upstream release: this is often needed when rebuilding something that's
+ previously been uploaded to Debian or Ubuntu or into a different PPA.)
+
+* Now merge across that change into each supported branch with a
+ simple ``bzr merge``.
+
+Locally testing using pbuilder
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It may be useful to locally test builds inside pbuilder. You may want to
+use the script from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255165>
+to wrap it, and to give it sensible defaults for your local machine.
+
+Update all packages in proposed before copying to the main ppa
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If one updates bzr, and there are plugins that are not compatible with the
+new version of bzr, this can cause pain for users using the ppa. In order to
+avoid this, we first get all packages up to date in the proposed ppa, and then
+copy them to the main ppa.
+
+
+Short form
+~~~~~~~~~~
+
+For people who have already set up everything they need, building the
+release packages is as simple as::
+
+ cd ~/dev/bzr/releases/packaging
+ export VERSION="1.17~rc1-1~bazaar1"
+ export PACKAGE="bzr"
+ export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
+ ~/dev/bzr/bzr.dev/tools/packaging/update-packaging-branches.sh
+ * Optionaly merge debian unstable.
+ ~/dev/bzr/bzr.dev/tools/packaging/update-changelogs.sh
+ ~/dev/bzr/bzr.dev/tools/packaging/update-control.sh 1.16 1.17 1.18
+ ~/dev/bzr/bzr.dev/tools/packaging/build-packages.sh
+ dput ppa:bzr/proposed ${PACKAGE}_$VERSION*.changes
+
+Rinse and repeat for all the plugins by changing VERSION and PACKAGE.
+
+Long Form
+~~~~~~~~~
+
+#. You will end up checking out a separate directory for each supported
+ release. Such as ``~/dev/bzr/releases/packaging/hardy``. In each of these
+ branches, you will produce the package for the release.
+
+ The scripts will also create the branches and produce packages for
+ bzrtools and bzr-svn.
+
+#. Decide on the final version number. It should be of this form::
+
+ bzr-1.17~rc1-1~bazaar1~hardy1
+
+ **Note:** There are three hyphen-separated parts: the *package name*,
+ the *upstream version*, and the *packaging version*.
+
+ **Caution:** Upstream betas or release candidates must insert a tilde
+ to make them sort before the final release, like this:
+ ``bzr-1.17~rc1-1~bazaar1~hardy1``.
+
+ Final releases will use a release string of the form:
+ ``bzr-1.17-1~bazaar1~hardy1``
+
+ Set this base of this up as a usable environment variable::
+
+ export VERSION="1.17~rc1-1~bazaar1"
+
+#. Export the distroreleases that you will be packaging for::
+
+ export UBUNTU_RELEASES="dapper hardy intrepid jaunty karmic"
+
+#. Export the program you are packaging::
+
+ export PACKAGE="bzr"
+
+#. Checkout (or update) the packaging branch for each supported release::
+
+ bzr co lp:~bzr/ubuntu/hardy/bzr/bzr-ppa
+
+ There is a script available to help::
+
+ tools/packaging/update-packaging-branches.sh
+
+#. Optionaly, merge the Debian unstable branch into each of the packaging
+ branches. You can find the Debian unstable branch here:
+ http://bzr.debian.org/pkg-bazaar/
+
+#. The ``bzr-builddeb`` step will download the original tarball if you do
+ not already have it, putting it into a ``tarballs`` directory.
+
+#. For Bazaar plugins, change the ``debian/control`` file to express a
+ dependency on the correct version of ``bzr``.
+
+ For bzrtools this is typically::
+
+ Build-Depends-Indep: bzr (>= 1.17~), rsync
+ Depends: ${python:Depends}, bzr (>= 1.17~), bzr (<< 1.18~), patch
+
+ There is a helper script which will update the control file and commit it
+ for all of your ``$UBUNTU_RELEASES``. It is available as::
+
+ tools/packaging/update-control.sh
+
+ You must supply the versions as arguments as follows
+ OLD_VERSION CURRENT_VERSION NEXT_VERSION, such as::
+
+ tools/packaging/update-control.sh 1.16 1.17 1.18
+
+#. Make a new ``debian/changelog`` entry for the new release,
+ either by using ``dch`` or just editing the file::
+
+ dch -v '1.17~rc1-1~bazaar1~hardy1' -D hardy
+
+ dch will default to the distro you're working in and this isn't checked
+ against the version number (which is just our convention), so make sure
+ to specify it.
+
+ Make sure you have the correct email address for yourself (you may need
+ export DEBEMAIL=`bzr whoami` if it isn't already set), version number, and
+ distribution. It should look something like this::
+
+ bzr (1.17~rc1-1~bazaar1~hardy1) hardy; urgency=low
+
+ * New upstream release.
+
+ -- John Sample <sample@example.com> Mon, 31 Mar 2008 12:36:27 +1100
+
+ If you need to upload the package again to fix a problem, normally you
+ should increment the last number in the version number, following the
+ distro name. Make sure not to omit the initial ``-1``, and make sure
+ that the distro name in the version is consistent with the target name
+ outside the parenthesis.
+
+ You will also want to commit these changes into the packaging branch.
+
+ There is a helper script which will build all the packages
+ for all of your ``$UBUNTU_RELEASES``. It is available as::
+
+ tools/packaging/update-changelogs.sh
+
+#. Build the source packages::
+
+ cd bzr-$DISTRO; bzr builddeb -S
+
+ This will create a ``.changes`` file. If you didn't configure builddeb
+ to automatically sign them, you can use ::
+
+ debsign -m$UID *.changes
+
+ where ``$UID`` is the gpg key you want to use to sign the changes.
+
+ There is a helper script which will build the package
+ for all of your ``$UBUNTU_RELEASES``. It is available as::
+
+ tools/packaging/build-packages.sh
+
+#. Upload into the PPA for each release::
+
+ dput dput ppa:bzr/proposed bzr*1.17-1*.changes
+
+#. You should soon get an "upload accepted" mail from Launchpad, which
+ means that your package is waiting to be built. You can then track its
+ progress in <https://launchpad.net/~bzr/+archive/proposed> and
+ <https://launchpad.net/~bzr/+archive/proposed/+builds>.
+
+
+Packaging bzr-svn
+~~~~~~~~~~~~~~~~~
+
+bzr-svn uses a packaging branch that contains both the source
+(including any changes against upstream) and the ``debian/`` directory.
+
+To build bzr-svn:
+
+#. Get a checkout of ``lp:~bzr/bzr-svn/hardy-ppa/``
+
+#. Merge from ``http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/``
+
+ This should bring in both upstream and packaging changes for the new
+ release, and it's updated as part of the bzr-svn release process.
+
+ It's quite possible you will need to resolve some conflicts.
+
+#. Run ``dch -v 0.4.15-1~bazaar1-hardy1 -D hardy`` or similar
+
+#. Run ``bzr builddeb --source``
+
+ bzr-builddeb will automatically check out the appropriate tag from the
+ main branch of bzr-svn, build, and package it.
+
+#. ``dput ppa:bzr/proposed ../bzr-svn_0.4.15-1~bazaar1~hardy1_source.changes``
+
+
+Monitoring the contents of PPAs
+-------------------------------
+
+If you add all the bzr PPAs to your ``sources.list`` then you can see a
+summary of current package versions with::
+
+ apt-cache madison bzr
+
+
+Testing the contents of the PPA
+-------------------------------
+
+A somewhat crude but useful way to test the contents of the PPA is to
+install the relevant packages into an schroot::
+
+ schroot -c hardy-test -u root -- \
+ apt-get install -o 'APT::Install-Suggests="true"' \
+ -o 'APT::Install-Recommends="true"' \
+ bzr
+
+This should make sure everything can be installed; it won't guarantee that
+
+
+Packaging dependencies
+----------------------
+
+Some of our updates to bzr in previous releases require backports of our
+dependencies. Specific branches holding these backports:
+
+ * ``lp:~bzr/ubuntu/dapper/configobj/dapper-backport``
+ * ``lp:~bzr/ubuntu/hardy/python-central-debhelper-sequence-addon/bzr-ppa``
+
+
+..
+ vim: filetype=rst textwidth=74 ai shiftwidth=4
diff --git a/doc/developers/principles.txt b/doc/developers/principles.txt
new file mode 100644
index 0000000..c2b0551
--- /dev/null
+++ b/doc/developers/principles.txt
@@ -0,0 +1,62 @@
+========================
+Bazaar Design Principles
+========================
+
+We have learned or adopted a few general principles for code in Bazaar.
+Generally we will try to follow them in future, either for consistency or
+because they've been proven to work well, or both.
+
+We may need to depart from these principles in particular special cases,
+or modify them as we learn more, or we might be diverging for them for no
+very good reason but just because of bugs. If in doubt, ask.
+
+See also: `Bazaar Developer Document Catalog <index.html>`_.
+
+
+Testing
+-------
+
+Untested code is broken code.
+
+So if a function is removed from the normal flow of execution (perhaps
+because a new default format was introduced) we have to make sure we can
+still execute and test the old code -- or remove it altogether.
+
+
+
+Data formats
+------------
+
+Fixing code once it's released is easy; fixing a problematic data format
+once people have started using it is more difficult. We should document
+and review formats separately from the code that implements them.
+
+Data formats should have clear format markers that allow us to support new
+formats in future. It should be easy to read the format without reading
+the whole object.
+
+The format marker should be a string understandable by a user that names
+the format and gives the bzr release that introduced it. If the bzr
+program doesn't understand that format, it can at least show that format
+marker to the user.
+
+Once we mark a format as supported, we'll continue supporting it for
+several future releases, and support upgrading from it
+forever.
+
+Once we've released a format, we normally don't change it. Adding new
+optional elements can cause problems when older clients don't understand
+those changes, or don't propagate them properly.
+
+We clearly distinguish internal files from user files. Files inside
+``.bzr/`` are only written to by bzr and we discourage users from editing
+them. Within bzr, code addressing the abstract interface of the Branch,
+BzrDir, etc shouldn't know where or how the internal files are stored. If
+anything else is written in there, it won't be propagated when pushing or
+pulling, and won't be converted when upgrading. (This is not quite true
+though; there is a ``branch.conf``.)
+
+User files within the tree, by contrast, we always store and return
+verbatim. It's OK for Bazaar to read and act on these files (as we do
+with ``.bzrignore``), and to update them (as ``bzr ignore`` does), but
+they remain clearly user files and can be directly edited.
diff --git a/doc/developers/profiling.txt b/doc/developers/profiling.txt
new file mode 100644
index 0000000..7446616
--- /dev/null
+++ b/doc/developers/profiling.txt
@@ -0,0 +1,64 @@
+Profiling
+=========
+
+Using profilers
+---------------
+
+Bazaar has some built-in support for collecting and saving profiling
+information. In the simpliest case, the ``--lsprof`` option can be used as
+shown below::
+
+ bzr --lsprof ...
+
+This will dump the profiling information to stdout before exiting.
+Alternatively, the ``--lsprof-file`` option can be used to specify a filename
+to save the profiling data into to. By default, profiling data saved to a
+file is a pickled Python object making it possible to reload the data and
+do with it what you will. For convenience though:
+
+* if the filename ends in ``.txt``, it will be dumped in a text format.
+
+* if the filename either starts with ``callgrind.out`` or ends with
+ ``.callgrind``, it will be converted to a format loadable by the
+ KCacheGrind visualization tool.
+
+Note that KCacheGrind's Open Dialog has a default filter than only shows
+files starting with ``callgrind.out`` so the longer filename is usually
+preferable. Here is an example of how to use the ``--lsprof-file`` option
+in combination with KCacheGrind to visualize what the ``status`` command
+is doing::
+
+ bzr --lsprof-file callgrind.out.st001 status
+ kcachegrind callgrind.out.st001 &
+
+.. Note:: bzr also has a ``--profile`` option that uses the hotshot profiler
+ instead of the lsprof profiler. The hotshot profiler can be useful
+ though the lsprof one is generally recommended. See
+ http://docs.python.org/lib/node795.html.
+
+Note that to use ``--lsprof`` you must install the lsprof module, which you
+can get with::
+
+ svn co http://codespeak.net/svn/user/arigo/hack/misc/lsprof
+
+
+Profiling locks
+---------------
+
+Bazaar can log when locks are taken or released, which can help in
+identifying unnecessary lock traffic. This is activated by the ``-Dlock``
+global option.
+
+This writes messages into ``~/.bzr.log``.
+At present this only logs actions relating to the on-disk lockdir. It
+doesn't describe actions on in-memory lock counters, or OS locks (which
+are used for dirstate.)
+
+
+Profiling HPSS Requests
+-----------------------
+
+When trying to improve network performance, it is often useful to know
+what requests are being made, and how long they are taking. The ``-Dhpss``
+global option will enable logging smart server requests, including the
+time spent in each request.
diff --git a/doc/developers/releasing.txt b/doc/developers/releasing.txt
new file mode 100644
index 0000000..7aeff38
--- /dev/null
+++ b/doc/developers/releasing.txt
@@ -0,0 +1,752 @@
+Releasing Bazaar
+################
+
+This document describes the processes for making and announcing a Bazaar
+release, and managing the release process. This is just one phase of the
+`overall development cycle
+<http://doc.bazaar.canonical.com/developers/cycle.html>`_, (go re-read this
+document to ensure it hasn't been updated since you last read it) but it's
+the most complex part.
+
+If you're doing your first release you can follow this document and read
+each step explanation. It's also a good practice to read it for any release
+to ensure you don't miss a step and to update it as the release process
+evolves.
+
+If you're helping the Release Manager (RM) for one reason or another, you
+may notice that he didn't follow that document scrupulously. He may have
+good reasons to do that but he may also have missed some parts.
+
+.. contents::
+
+
+Preconditions
+=============
+
+#. PQM access rights (or you won't be able to land any change)
+
+#. Download the pqm plugin and install it into your ``~/.bazaar/plugins``::
+
+ bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
+
+#. Alternatively, you can download and install ``lp:hydrazine`` (the main
+ difference is that hydrazine requires the branch to land to be hosted on
+ launchpad).
+
+What do we release
+==================
+
+In this document, we're talking about source releases only, packages and
+installers are built from this but we won't talk about them here.
+
+Every release is part of a series, ``bzr-2.4.1`` is part of series ``2.4``.
+
+We do two different kind of releases: the betas releases and the stable
+releases for a given series.
+
+For a given series, releases will be done to deliver new versions of bzr to
+different kinds of users:
+
+#. beta releases: named ``x.ybn`` where ``x.y`` is the series and ``n``
+ starts at 1 and is incremented. These releases are targeted to beta
+ testers who don't want to run from source but are interested in features
+ or improvements.
+
+#. stable releases: name ``x.y.z`` where ``x.y.`` is the series and ``z``
+ starts at 1 and is incremented. These releases are targeted at people
+ that want bugfixes only and no new features.
+
+
+Differences in the release process between beta and stable release will be
+mentioned when needed.
+
+When do we relase ?
+===================
+
+As of July 2011, we maintain four series (and one that is about to be EOLed).
+Concurrently releasing them all at the same time makes it harder to shorten
+the delay between the source availability and the package building longer
+than necessary (we delay the official announcement until most of our users
+can install the new release).
+
+In order to continue to do time-based releases, we need to plan the
+releases by series to minimize the collisions. In the end, it's the Release
+Manager call to decide whether he prefers to do all releases at once
+though, so the rules presented here are a conservative approach.
+
+We want to respect the following rules:
+
+#. as much as possible releases should not disturb development, and
+ ongoing development should not disturb releases,
+
+#. the most recent development series should release once a month during
+ the beta period (see `Development cycles <cycle.html>`_ for more
+ details),
+
+#. the most recent stable series should release every other month (based
+ on the amount of bug fixes, this can be shorter or longer depending on
+ the bugs importance),
+
+#. previous series should release on a regular basis without interfering
+ with the most recent series with a decreasing order of priority (again
+ this should be based on bugs importance and user feedback),
+
+#. the death of a series should be planned ahead of time. 6 months should
+ give enough time to our users to migrate to a more recent series. This
+ doesn't mean we will make a release at the end of the series, just that
+ before the end date we *could* possibly put out another release if
+ there was a sufficiently important fix. Beyond that date, we won't
+ even land changes on that branch (unless something causes a miraculous
+ resurrection.)
+
+#. there should not be more than 2 releases in the same week (but the
+ Release Manager is free to ignore this (get in touch with packagers
+ though),
+
+#. the series are aligned with Ubuntu releases for convenience since we
+ create a new series every 6 months. This means that we support the
+ stable series for 18 months. Note that we also propose the most recent
+ stable series via the stable PPA but that the SRU processs allow us to
+ reach a wider audience.
+
+At the start of a series cycle
+==============================
+
+To start a new series cycle:
+
+#. Create a new series ``x.y`` at <https://launchpad.net/bzr/+addseries>.
+
+#. Add milestones at <https://launchpad.net/bzr/x.y/+addmilestone> to that
+ series for the beta releases and the stable series mentioning their
+ expected dates. Only the milestone associated to the next release in
+ this series should be left active to avoid clutter when targeting bugs.
+
+#. If you made a new series, you will need to create a new pqm-controlled
+ branch for this release series. This branch will be used only from the
+ first non-beta release onwards. It needs to be created by a Canonical
+ sysadmin (ask the core devs for instructions or to do it for you).
+
+#. Start a new release-notes file::
+
+ cd doc/en/release-notes
+ cp series-template.txt bzr-x.y.txt # e.g. bzr-2.3.txt
+ bzr add bzr-x.y.txt
+
+#. Start a new whats-new file::
+
+ cd doc/en/whats-new
+ cp template.txt bzr-x.y.txt # e.g. bzr-2.6.txt
+ bzr add bzr-x.y.txt
+
+#. Update ``doc/en/index.txt`` to point to the new whats-new file.
+
+At the start of a release cycle
+===============================
+
+To start a new release cycle:
+
+#. Send mail to the list with the key dates, who will be the release
+ manager, and the main themes or targeted bugs. Ask people to nominate
+ objectives, or point out any high-risk things that are best done early,
+ or that interact with other changes. This is called the metronome mail
+ and is described in `Development cycles <cycle.html>`_.
+
+#. Make a local branch to prepare the release::
+
+ bzr branch lp:bzr/x.y x.y-dev
+
+ If you're doing your first beta release, branch from trunk::
+
+ bzr branch lp:bzr x.y-dev
+
+ Note that you will generally reuse the same branch for all releases in a
+ given series.
+
+#. Configure pqm-submit for this branch, with a section like this (where
+ ``x.y`` is the series for your release). **Or use hydrazine for easier
+ setup** ``~/.bazaar/locations.conf``::
+
+ [/home/mbp/bzr/x.y-dev]
+ pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
+ submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
+ parent_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
+ public_branch = http://bazaar.example.com/x.y-dev
+ submit_to = bazaar@lists.canonical.com
+ smtp_server = mail.example.com:25
+
+ Please see <http://doc.bazaar.canonical.com/developers/HACKING.html#an-overview-of-pqm>
+ for more details on PQM
+
+#. Update the version number in the ``bzr`` script, and the
+ ``bzrlib/__init__.py`` file::
+
+ version_info = (x, y, z, 'dev', 0)
+
+#. Add a new section at the top of the current release notes (in
+ ``doc/en/release-notes``) about the new release, including its version
+ number and the headings from ``release-template.txt``.
+
+#. Update the "What's New" documents in ``doc/en/whats-new``.
+
+#. Make sure a milestone exists for your release and that it is active,
+ <https://launchpad.net/bzr/x.y> lists the existing milestones,
+ <https://launchpad.net/bzr/x.y/x.y.z/+edit> allows you to toggle the
+ active flag.
+
+#. Commit this and send it to PQM.
+
+
+Doing a particular release
+==========================
+
+Update the source code
+----------------------
+
+#. Check that there is a milestone for the release you're doing. If there
+ is no milestone it indicates a process problem - make the milestone but
+ also mail the list to raise this issue in our process. Milestones are
+ found at <https://launchpad.net/bzr/+milestone/x.y.z>.
+
+#. Merge into your branch all previous stable series fixes that haven't been
+ merged yet. For example, if you're releasing 2.6.x, make sure the fixes
+ on 2.5, 2.4, 2.3, etc have already been merged up::
+
+ bzr merge lp:bzr/2.4
+
+ and commit that merge in its own commit. This should happen only if the
+ devs landing changes in previous releases forgot to merge them up. Since
+ this can slow down the freeze, feel free to gently remind them about
+ their duties ;) If you feel unsafe resolving the conflicts or it's too
+ time consuming, contact the related devs and skip this merge.
+
+#. In the release branch, update ``version_info`` in ``./bzrlib/__init__.py``.
+ Make sure the corresponding milestone exists.
+ Double check that ./bzr ``_script_version`` matches ``version_info``. Check
+ the output of ``./bzr --version``.
+
+ For beta releases use::
+
+ version_info = (2, 6, 0, 'beta', SERIAL)
+
+ For instance 2.6b1::
+
+ version_info = (2, 6, 0, 'beta', 1)
+
+ For stable releases use::
+
+ version_info = (2, 6, 0, 'final', 0)
+
+#. Update the ``./doc/en/release-notes/`` section for this release.
+
+ Check that all news entries related to this release have been added in
+ the right section. For example, if you're releasing 2.6b1, the following
+ command should display a a single chuk diff for the 2.6b1 release::
+
+ bzr diff -rbzr-2.6b1.. doc/en/release-notes/bzr-2.6.txt
+
+ Fill out the date and a description of the release under the existing
+ header (the diff above will help you summarizing). If there isn't one,
+ follow the instructions above for using the ``release-template.txt`` file
+ and remind people that they should document their changes there ;)
+
+ See *2.6b1* or similar for an example of what this looks like.
+
+#. Add or check the summary of the release into the "What's New" document.
+
+ If this is the first release in a new series make sure to update the
+ introduction mentioning:
+
+ * the date of this first release,
+ * until when the series is expected to be supported.
+
+ Looking at ``bzr annotate`` for previous series should give you the right
+ hints. The ``doc/en/_templates/index.html`` file should also be updated.
+
+#. To check that all bugs mentioned in the release notes are actually
+ marked as closed in Launchpad, you can run
+ ``tools/check-newsbugs.py``::
+
+ ./tools/check-newsbugs.py doc/en/release-notes/bzr-x.y.txt
+
+ As of 2011-07-18, all bugs mentioned in the output of the script requires
+ some sort of intervention (either changing the status if it's not 'Fix
+ Released' or setting a different milestone if the bug hasn't been
+ fixed). A few false positives may remain in the older series, don't let
+ this slow you down too much. This script accepts options you may find
+ useful, use ``./tools/check-newsbugs.py`` to display its usage (``-w``
+ will open each bug in your browser for example).
+
+#. For beta releases update the translation template::
+
+ BZR_PLUGIN_PATH=-site make po/bzr.pot
+
+ This is especially important for the final beta release which is when
+ translations are frozen and translators are requested (see `The final
+ beta - branching and translations`_) to make the translations.
+
+#. For stable releases update the translations::
+
+ bzr merge lp:~bzr-core/bzr/bzr-translations-export-x.y
+
+#. Commit these changes to the release branch, using a command like::
+
+ bzr commit -m "Release 2.3.1"
+
+ The diff before you commit will be something like::
+
+ === modified file 'bzrlib/__init__.py'
+ --- bzrlib/__init__.py 2011-02-09 06:35:00 +0000
+ +++ bzrlib/__init__.py 2011-03-10 10:24:47 +0000
+ @@ -52,7 +52,7 @@
+ # Python version 2.0 is (2, 0, 0, 'final', 0)." Additionally we use a
+ # releaselevel of 'dev' for unreleased under-development code.
+
+ -version_info = (2, 3, 1, 'dev', 0)
+ +version_info = (2, 3, 1, 'final', 0)
+
+ # API compatibility version
+ api_minimum_version = (2, 3, 0)
+
+ === modified file 'doc/en/release-notes/bzr-2.3.txt'
+ --- doc/en/release-notes/bzr-2.3.txt 2011-03-09 08:30:16 +0000
+ +++ doc/en/release-notes/bzr-2.3.txt 2011-03-10 10:40:47 +0000
+ @@ -8,23 +8,10 @@
+ bzr 2.3.1
+ #########
+
+ -:2.3.1: NOT RELEASED YET
+ -
+ -External Compatibility Breaks
+ -*****************************
+ -
+ -.. These may require users to change the way they use Bazaar.
+ -
+ -New Features
+ -************
+ -
+ -.. New commands, options, etc that users may wish to try out.
+ -
+ -Improvements
+ -************
+ -
+ -.. Improvements to existing commands, especially improved performance
+ - or memory usage, or better results.
+ +:2.3.1: 2011-03-10
+ +
+ +This is a bugfix release. Upgrading is recommended for all users of earlier
+ +2.3 releases.
+
+ Bug Fixes
+ *********
+
+ === modified file 'doc/en/whats-new/whats-new-in-2.3.txt'
+ --- doc/en/whats-new/whats-new-in-2.3.txt 2011-02-03 16:29:18 +0000
+ +++ doc/en/whats-new/whats-new-in-2.3.txt 2011-03-10 11:10:36 +0000
+ @@ -17,8 +17,13 @@
+ improvements made to the core product, it highlights enhancements within the
+ broader Bazaar world of potential interest to those upgrading.
+
+ -Bazaar 2.3.0 is fully compatible both locally and on the network with 2.0 2.1,
+ -and 2.2, and can read and write repositories generated by all previous
+ +Bazaar 2.3.1 includes all the fixes in the un-released 2.0.7, 2.1.4 and 2.2.5
+ +versions that weren't included in 2.3.0 and fixes some bugs on its own.
+ +
+ +See the :doc:`../release-notes/index` for details.
+ +
+ +Bazaar 2.3 is fully compatible both locally and on the network with 2.0, 2.1,
+ +and 2.2. It can read and write repositories generated by all previous
+ versions.
+
+ Changed Behaviour
+
+
+#. Tag the new release::
+
+ bzr tag bzr-2.6.0
+
+#. Push those changes to a bzr branch that is public and accessible on the
+ Internet. PQM will pull from this branch when it attempts to merge your
+ changes. Then submit those changes to PQM for merge into the appropriate
+ release branch::
+
+ bzr push
+ bzr pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
+
+ Note that ``bzr push`` should mention updating one tag (which you just
+ created). If it doesn't, double-check that you created (and pushed) this
+ tag.
+
+ Or with hydrazine::
+
+ bzr lp-propose -m "Release 1.14" --approve lp:bzr/1.14
+ feed-pqm bzr
+
+#. When PQM succeeds, pull down the master release branch.
+
+
+Making the source tarball
+-------------------------
+
+#. Change into the source directory and run ::
+
+ make dist
+
+#. Now we'll try expanding this tarball and running the test suite
+ to check for packaging problems::
+
+ make check-dist-tarball | subunit2pyunit
+
+ You may encounter failures while running the test suite caused by your
+ locally installed plugins. Use your own judgment to decide if you can
+ release with these failures. When in doubt, disable the faulty plugins
+ one by one until you get no more failures. Alternatively, you can use
+ ``BZR_DISABLE_PLUGINS`` or ``BZR_PLUGIN_PATH=-site`` to disable one or
+ all plugins.
+
+ Until <http://pad.lv/839461> is fixed, you may encounter issues if you
+ cut a release for old stable branches (<= 2.2) and use a more recent
+ OS/distro. If that's the case, check the bug status and use the following
+ workaround if no fix is available::
+
+ export TTPATH=<local branch of lp:testtools -r 0.9.2>
+ export SUPATH=<local branch of lp:subunit -r 0.0.6>
+ PYTHONPATH=$TTPATH:$SUPATH/python PATH=$SUPATH/filters:${PATH} BZR_PLUGIN_PATH=-site make check-dist-tarball PYTHON=python2.6 | subunit2pyunit
+
+ Remember that PQM has just tested everything too, this step is
+ particularly testing that the pyrex extensions, which are updated
+ by your local pyrex version when you run make dist, are in good
+ shape.
+
+
+Publishing the source tarball
+-----------------------------
+
+#. Go to the relevant <https://launchpad.net/bzr/x.y> series page in Launchpad.
+
+#. Create a release of the milestone, and upload the source tarball and
+ the GPG signature. Or, if you prefer, use the
+ ``tools/packaging/lp-upload-release`` script to do this. Note that
+ this changes what the download widget on the Launchpad bzr home
+ page shows, so don't stop the release process yet, or platform binary
+ installers won't be made and the download list will stay very small!
+ <https://bugs.launchpad.net/launchpad/+bug/586445>
+
+
+Kick off the next cycle
+-----------------------
+
+From that point, there is no possible return, the tarball has been uploaded
+so you can relax a bit.
+
+You're still holding a "social" lock on the launchpad branch though. Until
+your start the next cycle, nobody should land anything on this branch. If
+they do, they either targeted the wrong branch or didn't update the news
+file correctly, so the sooner the branch is opened again, the better.
+
+This matters more for ``lp:bzr`` than for ``lp:bzr/x.y``, ``lp:bzr`` should
+always be open for landing, so you should do `At the start of a release
+cycle`_ as soon as possible (i.e. update the version number in ``bzr`` and
+``bzrlib/__init__``, create/update the news files and create/update the
+milestone for the next relase).
+
+You may also need to do `At the start of a series cycle`_ if you're starting
+a new series.
+
+The final beta - branching and translations
+-------------------------------------------
+
+A word of caution: the instructions above works well for all releases but
+there is one special case that requires a bit more care: when you release
+the *last* beta for a given ``x.y`` series (from trunk aka lp:bzr), you need
+to setup *two* branches for the next cycle:
+
+#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``.
+
+#. ``lp:bzr/x.y`` needs to be opened for the next *release* ``x.y.0`` in the
+ series. Since this is first real use of ``lp:bzr/x.y``, this is also the
+ deadline for the PQM branch to be created.
+
+Both are important as ``lp:bzr`` should remain open so any change can be
+landed, ``lp:bzr/x.y`` on the other hand should be ready to receive bug
+fixes.
+
+``lp:bzr`` is generally more important as the bug fixes on ``lp:bzr/x.y``
+won't be released sooner than a month from now whereas people may already
+been waiting to land on ``lp:bzr``.
+
+In a nutshell:
+
+#. Open ``lp:bzr`` for ``x.(y+1)``
+
+#. Create or update the ``x.y`` PQM branch based on whatever revision you
+ want to release. Since it takes time to create the PQM branch for the new
+ series you should plan to get it created a few days before you need it
+ and seed it with the revision from trunk you want to base your release of
+ (ask a LOSA for pulling this revision from trunk and pushing it to the
+ series branch (``lp:bzr/x.y``) when you're ready).
+
+#. Release ``x.y.0`` from ``lp:bzr/x.y``
+
+#. Open ``lp:bzr/x.y`` for bug fixes
+
+You also need to ensure Launchpad is set up to import/export translations
+for the new branch and inform translators.
+
+#. Push the last beta release to a new branch::
+
+ bzr push lp:~bzr-core/bzr/bzr-translations-export-x.y
+
+#. On the translations series synchronization settings page
+ <https://translations.launchpad.net/bzr/x.y/+translations-settings>
+ turn on ``Import template files`` then for exports click ``Choose a
+ target branch`` and point it at the branch you just pushed.
+
+#. E-mail translators to announce that the forthcoming stable release of bzr
+ is ready for translations. Send to
+ ``launchpad-translators@lists.launchpad.net`` and
+ ``ubuntu-translators@lists.ubuntu.com``.
+
+#. The series is now frozen for strings and API, see below for adding
+ that to the announcement.
+
+Announcing the source freeze
+----------------------------
+
+#. Post to the ``bazaar@lists.canonical.com`` and
+ ``bzr-packagers@list.launchpad.net`` lists, saying that the source has
+ been frozen. Be extra clear that this is only a *source* release targeted
+ at packagers and installer builders (see
+ <https://bugs.launchpad.net/launchpad/+bug/645084>). This is the cue for
+ platform maintainers and plugin authors to update their code. This is
+ done before the general public announcement of the release.
+
+ The freeze announcement generally guess the date of the official public
+ announcement, for the most recent stable series (the one supported by the
+ installers and most of the distributions) it's generally a few days after
+ the freeze. For older series supported only via SRUs for Ubuntu, we don't
+ control the process as tightly so guessing the date is not appropriate.
+
+ For the final beta release include in your announcement a notice of
+ API and translation freezes noting that public methods should not
+ be removed or changed and strings should not be added or changed.
+
+#. Pause for a few days.
+
+
+Publishing the release
+----------------------
+
+There is normally a delay of a few days after the source freeze to allow
+for binaries to be built for various platforms. Once they have been built,
+we have a releasable product. The next step is to make it generally
+available to the world.
+
+#. Go to the release web page at <https://launchpad.net/bzr/x.y/x.y.z>
+
+#. Announce on the `Bazaar website <http://bazaar.canonical.com/>`_.
+ This page is edited via the lp:bzr-website branch. (Changes
+ pushed to this branch are refreshed by a cron job on escudero.)
+
+#. Check that the documentation for this release is available in
+ <http://doc.bazaar.canonical.com>. It should be automatically build when
+ the branch is created, by a cron script ``update-bzr-docs`` on
+ ``escudero``. When the first release is created in a new series, a branch
+ needs to be created on escudero::
+
+ ssh escudero.canonical.com
+ sudo -u bzr-web -s
+ cd /srv/doc.bazaar.canonical.com/
+ bzr branch http://bazaar.launchpad.net/~bzr-pqm/bzr/2.5 bzr.2.5
+
+ And the ``update-bzr-docs`` needs to refer to it.
+
+ The ``lp:bzr-alldocs`` branch also needs to be updated when a new series
+ is introduced, see the ``README`` file there for more instructions
+ (looking at the branch history is also a good way to understand what
+ needs to be done and to document any policy changes).
+
+Announcing the release
+----------------------
+
+Now that the release is publicly available, tell people about it.
+
+#. Make an announcement mail.
+
+ For beta releases, this is sent to the ``bazaar@lists.canonical.com`` and
+ ``bazaar-announce@lists.canonical.com`` lists.
+
+ For stable releases (excluding SRUs which are for older stable releases),
+ it should also be cc'd to ``info-gnu@gnu.org``,
+ ``python-announce-list@python.org``, ``bug-directory@gnu.org``.
+
+ In all cases, it is good to set ``Reply-To: bazaar@lists.canonical.com``,
+ so that people who reply to the announcement don't spam other lists.
+
+ The announce mail will look something like this::
+
+ Subject: bzr x.y.z released!
+
+ The Bazaar team is happy to announce availability of a new
+ release of the bzr adaptive version control system.
+
+ Bazaar <http://bazaar.canonical.com/> is a Canonical project and part
+ of the GNU project <http://gnu.org/> to produce a free operating
+ system.
+
+ <<Summary paragraph from news>>
+
+ Thanks to everyone who contributed patches, suggestions, and
+ feedback.
+
+ Bazaar is now available for download from
+ https://launchpad.net/bzr/x.y/x.y.z/ as a source tarball; packages
+ for various systems will be available soon.
+
+ <<release notes from this release back to the last major release>>
+
+ Feel free to tweak this to your taste.
+
+#. Make an announcement through <https://launchpad.net/bzr/+announce>
+ mentioning the milestone URL <https://launchpad.net/bzr/+milestone/x.y.z>
+ so people get an easy access to details.
+
+#. Announce on http://freecode.com/projects/bazaar-vcs
+
+ This should be done for beta releases and stable releases. If you do not
+ have a Freecode account yet, ask one of the existing admins.
+
+ The purpose here is to point users to the latest stable release
+ (i.e. SRUs are excluded) while still publishing announcements for beta
+ releases.
+
+ There are several kinds of modifications that could be done there via the
+ ``Administration`` box in the lower right area of the page:
+
+ * Edit the project: This is where most of the URLs proposed in the
+ ``Links`` box are edited. This should rarely change except for the URLs
+ related to the latest stable release.
+
+ * New announcement: When doing a release, put the summary of the release
+ (you can't embed URLs there, the moderation staff remove them). Users
+ can still access the releases notes via the ``Release Notes`` URL in
+ the ``Links`` box in the upper right area of the page. When doing the
+ first stable release in a series, delete the ``Unstable installers``
+ <https://launchpad.net/bzr/x.y/x.ybn> and ``Unstable source tarball``
+ <http://launchpad.net/bzr/x.y/x.ybn/+download/bzr-x.ybn.tar.gz>
+ links. Conversely, when creating the first beta in a development
+ series, create these links again. Check all links when doing other
+ kinds of release.
+
+#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
+ be done for the stable and beta releases.
+
+#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
+ done by running ::
+
+ python setup.py register
+
+ Remember to check the results afterward -- this should be done for
+ stable releases but not for beta releases nor SRUs.
+
+ To be able to register the release you must create an account on
+ <http://pypi.python.org/pypi> and have one of the existing owners of
+ the project add you to the group.
+
+
+Merging the released code back to trunk
+---------------------------------------
+
+Merge the release branch back into the trunk. The ``doc/en/release-notes``
+changes should be merged into the right place because each release series
+has its own release-notes file, but double-check.
+
+If it's not already done, advance the version number in ``bzr`` and
+``bzrlib/__init__.py``. Submit this back into pqm for bzr.dev.
+
+As soon as you change the version number in trunk, make sure you have
+created the corresponding milestone to ensure the continuity in bug
+targeting or nominating. Depending on the change, you may even have to
+create a new series (if your change the major or minor release number), in
+that case go to `At the start of a series cycle`_ and follow the
+instructions from there.
+
+
+Releases until the final one
+----------------------------
+
+Congratulations - you have made your first release. Have a beer or fruit
+juice - it's on the house! If it was a beta, you're not finished
+yet. Another beta or hopefully a stable release is still to come.
+
+The process is the same as for the first release. Goto `Doing a particular
+release`_ and follow the instructions again. Some details change between
+beta and stable releases, but they should be documented. If the instructions
+aren't clear enough, please fix them.
+
+
+Getting the release into Ubuntu
+-------------------------------
+
+(Feel free to propose or add new sections here about what we should do to
+get bzr into other places.)
+
+For the currently-under-development release of Ubuntu, no special action
+is needed: the release should be picked by Debian and synced from there into
+Ubuntu.
+
+Releases off stable bzr branches should go in to the ``-updates`` of the
+Ubuntu release that originally contained that branch. (Ubuntu Lucid had
+bzr 2.2.0, so should get every 2.2.x update.) This means going through
+the `SRU (Stable Release Updates)
+<https://wiki.ubuntu.com/StableReleaseUpdates>`__ process.
+
+Since September 2010, bzr has received approval by the technical
+board for the `MicroReleaseExceptions
+<https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions>`__
+category so that whole bugfix releases can more easily be
+approved.
+
+Progress on these realeases is tracked on the `SRU wiki
+<http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates>`_
+page.
+
+**After making a bzr stable-release release, nominate the most serious bug
+for the appropriate Ubuntu release and subscribe the `ubuntu-sru` team.**
+
+This requires a couple of tricks (please reconsider and tweak as things
+evolves from one release to the other):
+
+ * create a distro task with the ``Also affects distribution`` button and
+ select ``bzr (Ubuntu)``.
+
+ * change the *URL* to point to ``ubuntu/+source/bzr`` instead of ``bzr``
+ (this is needed if you create the distro task but not if it exists
+ already). You should now be able to click the ``Nominate for release``
+ button and select the right Ubuntu release. As of September 2010, this
+ means:
+
+ * ``oneiric`` for the 2.4 series,
+ * ``natty`` for the 2.3 series,
+ * ``maverick`` for the 2.2 series,
+ * ``lucid`` for the 2.1 series,
+
+ * Subscribe the ``~ubuntu-sru`` team to the bug.
+
+ * Add a comment targeted to ``~ubuntu-sru`` explaining the expectations
+ (we are targeting running the test suite during the build which, as of
+ September 2010, fails for known reasons that are currently addressed).
+ Search for bugs tagged with ``sru`` for examples and don't forget to tag
+ the bug you selected.
+
+
+See also
+--------
+
+* `Packaging into the bzr PPA <ppa.html>`_ to make and publish Ubuntu
+ packages.
+* `Bazaar Developer Document Catalog <index.html>`_
+* `Development cycles <cycle.html>`_: things that happen during the cycle
+ before the actual release.
+
+..
+ vim: filetype=rst textwidth=74 ai shiftwidth=4
diff --git a/doc/developers/repository-stream.txt b/doc/developers/repository-stream.txt
new file mode 100644
index 0000000..87eba7f
--- /dev/null
+++ b/doc/developers/repository-stream.txt
@@ -0,0 +1,200 @@
+==================
+Repository Streams
+==================
+
+Status
+======
+
+:Date: 2008-04-11
+
+This document describes the proposed programming interface for streaming
+data from and into repositories. This programming interface should allow
+a single interface for pulling data from and inserting data into a Bazaar
+repository.
+
+.. contents::
+
+
+Motivation
+==========
+
+To eliminate the current requirement that extracting data from a
+repository requires either using a slow format, or knowing the format of
+both the source repository and the target repository.
+
+
+Use Cases
+=========
+
+Here's a brief description of use cases this interface is intended to
+support.
+
+Fetch operations
+----------------
+
+We fetch data between repositories as part of push/pull/branch operations.
+Fetching data is currently an very interactive process with lots of
+requests. For performance having the data be supplied in a stream will
+improve push and pull to remote servers. For purely local operations the
+streaming logic should help reduce memory pressure. In fetch operations
+we always know the formats of both the source and target.
+
+Smart server operations
+~~~~~~~~~~~~~~~~~~~~~~~
+
+With the smart server we support one streaming format, but this is only
+usable when both the client and server have the same model of data, and
+requires non-optimal IO ordering for pack to pack operations. Ideally we
+can both provide optimal IO ordering the pack to pack case, and correct
+ordering for pack to knits.
+
+Bundles
+-------
+
+Bundles also create a stream of data for revisions from a repository.
+Unlike fetch operations we do not know the format of the target at the
+time the stream is created. It would be good to be able to treat bundles
+as frozen branches and repositories, so a serialised stream should be
+suitable for this.
+
+Data conversion
+---------------
+
+At this point we are not trying to integrate data conversion into this
+interface, though it is likely possible.
+
+
+Characteristics
+===============
+
+Some key aspects of the described interface are discussed in this section.
+
+Single round trip
+-----------------
+
+All users of this should be able to create an appropriate stream from a
+single round trip.
+
+Forward-only reads
+------------------
+
+There should be no need to seek in a stream when inserting data from it
+into a repository. This places an ordering constraint on streams which
+some repositories do not need.
+
+
+Serialisation
+=============
+
+At this point serialisation of a repository stream has not been specified.
+Some considerations to bear in mind about serialisation are worth noting
+however.
+
+Weaves
+------
+
+While there shouldn't be too many users of weave repositories anymore,
+avoiding pathological behaviour when a weave is being read is a good idea.
+Having the weave itself embedded in the stream is very straight forward
+and does not need expensive on the fly extraction and re-diffing to take
+place.
+
+Bundles
+-------
+
+Being able to perform random reads from a repository stream which is a
+bundle would allow stacking a bundle and a real repository together. This
+will need the pack container format to be used in such a way that we can
+avoid reading more data than needed within the pack container's readv
+interface.
+
+
+Specification
+=============
+
+This describes the interface for requesting a stream, and the programming
+interface a stream must provide. Streams that have been serialised should
+expose the same interface.
+
+Requesting a stream
+-------------------
+
+To request a stream, three parameters are needed:
+
+ * A revision search to select the revisions to include.
+ * A data ordering flag. There are two values for this - 'unordered' and
+ 'topological'. 'unordered' streams are useful when inserting into
+ repositories that have the ability to perform atomic insertions.
+ 'topological' streams are useful when converting data, or when
+ inserting into repositories that cannot perform atomic insertions (such
+ as knit or weave based repositories).
+ * A complete_inventory flag. When provided this flag signals the stream
+ generator to include all the data needed to construct the inventory of
+ each revision included in the stream, rather than just deltas. This is
+ useful when converting data from a repository with a different
+ inventory serialisation, as pure deltas would not be able to be
+ reconstructed.
+
+
+Structure of a stream
+---------------------
+
+A stream is an object. It can be consistency checked via the ``check``
+method (which consumes the stream). The ``iter_contents`` method can be
+used to iterate the contents of the stream. The contents of the stream are
+a series of top level records, each of which contains one or more
+bytestrings (potentially as a delta against another item in the
+repository) and some optional metadata.
+
+
+Consuming a stream
+------------------
+
+To consume a stream, obtain an iterator from the streams
+``iter_contents`` method. This iterator will yield the top level records.
+Each record has two attributes. One is ``key_prefix`` which is a tuple key
+prefix for the names of each of the bytestrings in the record. The other
+attribute is ``entries``, an iterator of the individual items in the
+record. Each item that the iterator yields is a factory which has metadata
+about the entry and the ability to return the compressed bytes. This
+factory can be decorated to allow obtaining different representations (for
+example from a compressed knit fulltext to a plain fulltext).
+
+In pseudocode::
+
+ stream = repository.get_repository_stream(search, UNORDERED, False)
+ for record in stream.iter_contents():
+ for factory in record.entries:
+ compression = factory.storage_kind
+ print "Object %s, compression type %s, %d bytes long." % (
+ record.key_prefix + factory.key,
+ compression, len(factory.get_bytes_as(compression)))
+
+This structure should allow stream adapters to be written which can coerce
+all records to the type of compression that a particular client needs. For
+instance, inserting into weaves requires fulltexts, so a stream would be
+adapted for weaves by an adapter that takes a stream, and the target
+weave, and then uses the target weave to reconstruct full texts (which is
+all that the weave inserter would ask for). In a similar approach, a
+stream could internally delta compress many fulltexts and be able to
+answer both fulltext and compressed record requests without extra IO.
+
+factory metadata
+~~~~~~~~~~~~~~~~
+
+Valid attributes on the factory are:
+ * sha1: Optional ascii representation of the sha1 of the bytestring (after
+ delta reconstruction).
+ * storage_kind: Required kind of storage compression that has been used
+ on the bytestring. One of ``mpdiff``, ``knit-annotated-ft``,
+ ``knit-annotated-delta``, ``knit-ft``, ``knit-delta``, ``fulltext``.
+ * parents: Required graph parents to associate with this bytestring.
+ * compressor_data: Required opaque data relevant to the storage_kind.
+ (This is set to None when the compressor has no special state needed)
+ * key: The key for this bytestring. Like each parent this is a tuple that
+ should have the key_prefix prepended to it to give the unified
+ repository key name.
+
+..
+ vim: ft=rst tw=74 ai
+
diff --git a/doc/developers/repository.txt b/doc/developers/repository.txt
new file mode 100644
index 0000000..304cc58
--- /dev/null
+++ b/doc/developers/repository.txt
@@ -0,0 +1,354 @@
+============
+Repositories
+============
+
+Status
+======
+
+:Date: 2007-07-08
+
+This document describes the services repositories offer and need to offer
+within bzrlib.
+
+
+.. contents::
+
+
+Motivation
+==========
+
+To provide clarity to API and performance tradeoff decisions by
+centralising the requirements placed upon repositories.
+
+
+Terminology
+===========
+
+A **repository** is a store of historical data for bzr.
+
+
+Command Requirements
+====================
+
+================== ====================
+Command Needed services
+================== ====================
+Add None
+Annotate Annotated file texts, revision details
+Branch Fetch, Revision parents, Inventory contents, All file texts
+Bundle Maximally compact diffs (file and inventory), Revision graph
+ difference, Revision texts.
+Commit Insert new texts, insert new inventory via delta, insert
+ revision, insert signature
+Fetching Revision graph difference, ghost identification, stream data
+ introduced by a set of revisions in some cheap form, insert
+ data from a stream, validate data during insertion.
+Garbage Collection Exclusive lock the repository preventing readers.
+Revert Delta from working tree to historical tree, and then
+ arbitrary file access to obtain the texts of differing
+ files.
+Uncommit Revision graph access.
+Status Revision graph access, revision text access, file
+ fingerprint information, inventory differencing.
+Diff As status but also file text access.
+Merge As diff but needs up to twice as many file texts -
+ base and other for each changed file. Also an initial
+ fetch is needed.
+Log Revision graph (entire at the moment) access,
+ sometimes status between adjacent revisions. Log of a
+ file needs per-file-graph. Dominator caching or
+ similar tools may be needed to prevent entire graph
+ access.
+Missing Revision graph access, and revision texts to show
+ output.
+Update As for merge, but twice.
+================== ====================
+
+Data access patterns
+====================
+
+Ideally we can make our data access for commands such as branch to
+dovetail well with the native storage in the repository, in the common
+case. Doing this may require choosing the behaviour of some commands to
+allow us to have a smaller range of access patterns which we can optimise
+more heavily. Alternatively if each command is very predicable in its
+data access pattern we may be able to hint to the low level layers which
+pattern is needed on a per command basis to get efficient behaviour.
+
+=================== ===================================================
+Command Data access pattern
+=================== ===================================================
+Annotate-cached Find text name in an inventory, Recreate one text,
+ recreate annotation regions
+Annotate-on demand Find file id from name, then breadth-first pre-order
+ traversal of versions-of-the-file until the annotation
+ is complete.
+Branch Fetch, possibly taking a copy of any file present in a
+ nominated revision when it is validated during fetch.
+Bundle Revision-graph as for fetch; then inventories for
+ selected revision_ids to determine file texts, then
+ mp-parent deltas for all determined file texts.
+Commit Something like basis-inventories read to determine
+ per-file graphs, insertion of new texts (which may
+ be delta compressed), generation of annotation
+ regions if the repository is configured to do so,
+ finalisation of the inventory pointing at all the new
+ texts and finally a revision and possibly signature.
+Fetching Revision-graph searching to find the graph difference.
+ Scan the inventory data introduced during the selected
+ revisions, and grab the on disk data for the found
+ file texts, annotation region data, per-file-graph
+ data, piling all this into a stream.
+Garbage Collection Basically a mass fetch of all the revisions which
+ branches point at, then a bait and switch with the old
+ repository thus removing unreferenced data.
+Revert Revision graph access for the revision being reverted
+ to, inventory extraction of that revision,
+ dirblock-order file text extract for files that were
+ different.
+Uncommit Revision graph access to synthesise pending-merges
+ linear access down left-hand-side, with is_ancestor
+ checks between all the found non-left-hand-side
+ parents.
+Status Lookup the revisions added by pending merges and their
+ commit messages. Then an inventory difference between
+ the trees involved, which may include a working tree.
+ If there is a working tree involved then the file
+ fingerprint for cache-misses on files will be needed.
+ Note that dirstate caches most of this making
+ repository performance largely irrelevant: but if it
+ was fast enough dirstate might be able to be simpler/
+Diff As status but also file text access for every file
+ that is different - either one text (working tree
+ diff) or a diff of two (revision to revision diff).
+Merge As diff but needs up to twice as many file texts -
+ base and other for each changed file. Also an initial
+ fetch is needed. Note that the access pattern is
+ probably id-based at the moment, but that may be
+ 'fixed' with the iter_changes based merge. Also note
+ that while the texts from OTHER are the ones accessed,
+ this is equivalent to the **newest** form of each text
+ changed from BASE to OTHER. And as the repository
+ looks at when data is introduced, this should be the
+ pattern we focus on for merge.
+Log Revision graph (entire at the moment) access, log of a
+ file wants a per-file-graph. Log -v will want
+ newest-first inventory deltas between revisions.
+Missing Revision graph access, breadth-first pre-order.
+Update As for merge, but twice.
+=================== ===================================================
+
+Patterns used
+-------------
+
+Note that these are able to be changed by changing what we store. For
+instance if the repository satisfies mpdiff requests, then bundle can be
+defined in terms of mpdiff lookups rather than file text lookups
+appropriate to create mpdiffs. If the repository satisfies full text
+requests only, then you need the topological access to build up the
+desired mpdiffs.
+
+=========================================== =========
+Pattern Commands
+=========================================== =========
+Single file text annotate, diff
+Files present in one revision branch
+Newest form of files altered by revisions merge, update?
+Topological access to file versions/deltas annotate-uncached
+Stream all data required to recreate revs branch (lightweight)
+Stream file texts in topological order bundle
+Write full versions of files, inv, rev, sig commit
+Write deltas of files, inv for one tree commit
+Stream all data introduced by revs fetch
+Regenerate/combine deltas of many trees fetch, pack
+Reconstruct all texts and validate trees check, fetch
+Revision graph walk fetch, pack, uncommit,
+ annotate-uncached,
+ merge, log, missing
+Top down access multiple invs concurrently status, diff, merge?, update?
+Concurrent access to N file texts diff, merge
+Iteration of inventory deltas log -v, fetch?
+=========================================== =========
+
+Facilities to scale well
+========================
+
+Indices
+-------
+
+We want < linear access to all data in the repository. This suggests
+everything is indexed to some degree.
+
+Often we know the kind of data we are accessing; which allows us to
+partition our indices if that will help (e.g. by reducing the total index
+size for queries that only care about the revision graph).
+
+Indices that support our data access patterns will usually display
+increased locality of reference, reducing the impact of a large indices
+without needing careful page size management or other tricks.
+
+We need repository wide indices. For the current repositories this is
+achieved by dividing the keyspace (revisions, signatures, inventories,
+per-fileid) and then having an append only index within each keyspace.
+For pack based repositories we will want some means to query the index of
+each component pack, presumably as a single logical index.
+
+It would be nice if indexing was made cleanly separate from storage. So
+that suggests indices don't know the meaning of the lookup; indices which
+offer particular ordering, or graph walking facilities will clearly need
+that information, but perhaps they don't need to know the semantics ?
+
+Index size
+~~~~~~~~~~
+
+Smaller indexes are good. We could go with one big index, or a different
+index for different operation styles. As multiple indices will occupy more
+space in total we should consider carefully about adding indices.
+
+Index ordering
+~~~~~~~~~~~~~~
+
+Looking at the data access patterns some operations such as graph walking
+can clearly be made more efficient by offering direct iteration rather
+than repeated reentry into the index - so having indices that support
+iteration in such a style would be useful eventually.
+
+Changing our current indexes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We can consider introducing cleaner indices in advance of a full pack
+based repository.
+
+There are many possibilities for this, but I've chosen one that seems ok
+to me for illustration.
+
+A key element is to consider when indices are updated. I think that the
+update style proposed for pack based repositories - write once, then when
+we group data again rewrite a new single index - is sufficent.
+
+Replace .kndx
+^^^^^^^^^^^^^
+
+We could discard the per-knit .kndx by writing a new index at the end of
+every bzr transaction indexing the new data introduced by the bzr
+operation. e.g. at the end of fetch. This can be based on the new
+``GraphIndex`` index type.
+
+Encoding a knit entry into a ``GraphIndex`` can be done as follows:
+
+* Change the key to include a prefix of the knit name, to allow filtering
+ out of data from different knits.
+* Encode the parents from the knit as the zeroth node reference list.
+* If the knit hunk was delta compressed encode the node it was delta
+ compressed against as the 1st node reference list (otherwise the 1st
+ node reference list will be empty to indicate no compression parents).
+* For the value encode similarly to the current knit format the byte
+ offset for the data record in the knit, the byte length for the data
+ record in the knit and the no-end-of-line flag.
+
+It's important to note that knit repositories cannot be regenerated by
+scanning .knits, so a mapped index is still irreplaceable and must be
+transmitted on push/pull.
+
+A potential improvement exists by specialising this further to not record
+data that is not needed - e.g. an index of revisions does not need to
+support a pointer to a parent compressed text as revisions.knit is not
+delta-compressed ever. Likewise signatures do not need the parent pointers
+at all as there is no 'signature graph'.
+
+Data
+----
+
+Moving to pack based repositories
+---------------------------------
+
+We have a number of challenges to solve.
+
+Naming of files
+~~~~~~~~~~~~~~~
+
+As long as the file name is unique it does not really matter. It might be
+interesting to have it be deterministic based on content, but there are no
+specific problems we have solved by doing that, and doing so would require
+hashing the full file. OTOH hashing the full file is a cheap way to detect
+bit-errors in transfer (such as windows corruption). Non-reused file names
+are required for data integrity, as clients having read an index will
+readv at arbitrary times later.
+
+Discovery of files
+~~~~~~~~~~~~~~~~~~
+
+With non-listable transports how should the collection of pack/index files
+be found ? Initially record a list of all the pack/index files from
+write actions. (Require writable transports to be listable). We can then
+use a heuristic to statically combine pack/index files later.
+
+Housing files
+~~~~~~~~~~~~~
+
+Combining indices on demand
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Merging data on push
+~~~~~~~~~~~~~~~~~~~~
+
+A trivial implementation would be to make a pack which has just the data
+needed for the push, then send that. More sophisticated things would be
+streaming single-pass creation, and also using this as an opportunity to
+increase the packedness of the local repo.
+
+Choosing compression/delta support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Caching and writeing of data
+============================
+
+Repositories try to provide a consistent view of the data within them
+within a 'lock context'.
+
+Locks
+-----
+
+Locks come in two flavours - read locks and write locks. Read locks allow
+data to be read from the repository. Write locks allow data to be read and
+signal that you intend to write data at some point. The actual writing of
+data must take place within a Write Group.
+
+Write locks provide a cache of repository data during the period of the
+write lock, and allow write_groups to be acquired. For some repositories
+the presence of a write lock is exclusive to a single client, for others
+which are lock free or use server side locks (e.g. svn), the write lock
+simply provides the cache context.
+
+Write Groups
+------------
+
+Write groups are the only allowed means for inserting data into a
+repository. These are created by ``start_write_group``, and concluded by
+either ``commit_write_group`` or ``abort_write_group``. A write lock must
+be held on the repository for the entire duration. At most one write
+group can be active on a repository at a time.
+
+Write groups signal to the repository the window during which data is
+actively being inserted. Several write groups could be committed during a
+single lock.
+
+There is no guarantee that data inserted during a write group will be
+invisible in the repository if the write group is not committed.
+Specifically repositories without atomic insertion facilities will be
+writing data as it is inserted within the write group, and may not be able
+to revert that data - e.g. in the event of a dropped SFTP connection in a
+knit repository, inserted file data will be visible in the repository. Some
+repositories have an atomic insertion facility, and for those
+all-or-nothing will apply.
+
+The precise meaning of a write group is format specific. For instance a
+knit based repository treats the write group methods as dummy calls,
+simply meeting the api that clients will use. A pack based repository will
+open a new pack container at the start of a write group, and rename it
+into place at commit time.
+
+
+..
+ vim: ft=rst tw=74 ai
+
diff --git a/doc/developers/revert.txt b/doc/developers/revert.txt
new file mode 100644
index 0000000..067d71e
--- /dev/null
+++ b/doc/developers/revert.txt
@@ -0,0 +1,26 @@
+Revert
+======
+
+Change users selected paths to be the same as those in a given revision making
+backups of any paths that bzr did not set the last contents itself.
+
+Least work we can hope to perform
+---------------------------------
+
+We should be able to do work proportional to the scope the user is reverting
+and the amount of changes between the working tree and the revision being
+reverted to.
+
+This depends on being able to compare unchanged subtrees without recursing so that the mapping of paths to revert to ids to revert can be done efficiently. Specifically we should be able to avoid getting the transitive closure of directory contents when mapping back to paths from ids at the start of revert.
+
+One way this might work is to:
+for the selected scopes, for each element in the wt:
+
+ 1. get hash tree data for that scope.
+ 1. get 'new enough' hash data for the siblings of the scope: it can be out of date as long as it's not older than the last move or rename out of that siblings scope.
+ 1. Use the hash tree data to tune the work done in finding matching paths/ids which are different in the two trees.
+
+For each thing that needs to change - group by target directory?
+
+ 1. Extract new content.
+ 1. Backup old content or replace-in-place (except windows where we move and replace).
diff --git a/doc/developers/revision-properties.txt b/doc/developers/revision-properties.txt
new file mode 100644
index 0000000..4150e66
--- /dev/null
+++ b/doc/developers/revision-properties.txt
@@ -0,0 +1,46 @@
+Revision Properties
+===================
+
+Bazaar repositories support setting of a key/value pairs for each revision.
+Applications can use these properties to store additional information
+about the revision.
+
+Usage
+-----
+
+In general, revision properties are set by passing keyword argument
+``revprops`` to method ``MutableTree.commit``. For example::
+
+ properties = {}
+ properties['my-property'] = 'test'
+ tree.commit(message, revprops=properties)
+
+Properties can be retrieved via the attribute ``properties`` of
+instances of the class ``Revision``::
+
+ if 'my-property' in revision.properties:
+ my_property = revision.properties['my-property']
+ ...
+
+Well-known properties
+---------------------
+
+At the moment, three standardized revision properties are recognized and used
+by bzrlib:
+
+ * ``authors`` - Authors of the change. This value is a "\\n" separated set
+ of values in the same format as the committer-id. This property can be
+ set by passing a list to the keyword argument ``authors`` of the function
+ ``MutableTree.commit``.
+ * ``author`` - Single author of the change. This property is deprecated in
+ favour of ``authors``. It should no longer be set by any code, but will
+ still be read. It is ignored if ``authors`` is set in the same revision.
+ * ``branch-nick`` - Nickname of the branch. This can be specified by the user,
+ but it defaults to the colocated branch name or the branch's directory name.
+ The value is set automatically in ``MutableTree.commit``.
+ * ``bugs`` - A list of bug URLs and their statuses. The list is separated
+ by the new-line character (\\n) and each entry is in format
+ '<URL> <status>'. Currently, bzrlib uses only status 'fixed'. See
+ `Bug Trackers`_ for more details about using this feature.
+
+.. _Bug Trackers: ../en/user-guide/index.html#bug-trackers
diff --git a/doc/developers/specifications.txt b/doc/developers/specifications.txt
new file mode 100644
index 0000000..40f0b70
--- /dev/null
+++ b/doc/developers/specifications.txt
@@ -0,0 +1,77 @@
+Specifications
+==============
+
+.. toctree::
+ :hidden:
+
+ revision-properties
+ api-versioning
+ apport
+ authentication-ring
+ bundles
+ container-format
+ groupcompress-design
+ indices
+ inventory
+ lca-merge
+ network-protocol
+ plugin-api
+ repository
+ repository-stream
+ case-insensitive-file-systems
+ development-repo
+ packrepo
+
+
+* `Revision Properties <revision-properties.html>`_ |--| An application
+ can set arbitrary per-revision key/value pairs to store app-specific
+ data.
+
+* `API versioning <api-versioning.html>`_ |--| bzrlib API versioning.
+
+* `Apport error reporting <apport.html>`_ |--| Capture data to report
+ bugs.
+
+* `Authentication ring <authentication-ring.html>`_ |--| Configuring
+ authentication.
+
+* `Bundles <bundles.html>`_ |--| All about bzr bundles.
+
+* `Container format <container-format.html>`_ |--| Notes on a container format
+ for streaming and storing Bazaar data.
+
+* `Groupcompress <groupcompress-design.html>`_ |--| Notes on the compression
+ technology used in CHK repositories.
+
+* `Indices <indices.html>`_ |--| The index facilities available within bzrlib.
+
+* `Inventories <inventory.html>`_ |--| Tree shape abstraction.
+
+* `LCA merge <lca-merge.html>`_ |--| A nice new merge algorithm.
+
+* `Network protocol <network-protocol.html>`_ |--| Custom network protocol.
+
+* `Plugin APIs <plugin-api.html>`_ |--| APIs plugins should use.
+
+* `Repositories <repository.html>`_ |--| What repositories do and are used for.
+
+* `Repository stream <repository-stream.html>`_ |--| Notes on streaming data
+ for repositories (a layer above the container format).
+
+* `Bazaar and case-insensitive file systems <case-insensitive-file-systems.html>`_
+ |--| How Bazaar operates on case-insensitive file systems such as commonly
+ found on Windows, USB sticks, etc.
+
+* `Development repository formats <development-repo.html>`_ |--| How to
+ work with repository formats that are still under development.
+ Contains instructions for those implementing new formats, of course,
+ but also for (bleeding-edge) end users of those formats.
+
+* `Knit pack repositories <packrepo.html>`_ |--| KnitPack repositories
+ (new in Bazaar 0.92).
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/developers/status.txt b/doc/developers/status.txt
new file mode 100644
index 0000000..dbe58c3
--- /dev/null
+++ b/doc/developers/status.txt
@@ -0,0 +1,100 @@
+The status command
+==================
+
+The status command is used to provide a pithy listing of the changes between
+two trees. Its common case is between the working tree and the basis tree, but
+it can be used between any two arbitrary trees.
+
+.. contents:: :local:
+
+UI Overview
+-----------
+
+Status shows several things in parallel (for the paths the user supplied mapped
+across the from and to tree, and any pending merges in the to tree).
+
+1. Single line summary of all new revisions - the pending merges and their
+ parents recursively.
+2. Changes to the tree shape - adds/deletes/renames.
+3. Changes to versioned content - kind changes and content changes.
+4. Unknown files in the to tree.
+5. Files with conflicts in the to tree.
+
+
+Ideal work for working tree to historical status
+------------------------------------------------
+
+We need to do the following things at a minimum:
+
+1. Determine new revisions - the pending merges and history.
+
+1. Retrieve the first line of the commit message for the new revisions.
+
+1. Determine the tree differences between the two trees using the users paths
+ to limit the scope, and resolving paths in the trees for any pending merges.
+ We arguably don't care about tracking metadata for this - only the value of
+ the tree the user commited.
+
+1. The entire contents of directories which are versioned when showing
+ unknowns.
+
+1. Whether a given unversioned path is unknown or ignored.
+
+1. The list conflicted paths in the tree (which match the users path
+ selection?)
+
+
+Expanding on the tree difference case we will need to:
+
+1. Stat every path in working trees which is included by the users path
+ selection to ascertain kind and execute bit.
+
+1. For paths which have the same kind in both trees and have content, read
+ that content or otherwise determine whether the content has changed. Using
+ our hash cache from the dirstate allows us to avoid reading the file in the
+ common case. There are alternative ways to achieve this - we could record
+ a pointer to a revision which contained this fileid with the current content
+ rather than storing the content's hash; but this seems to be a pointless
+ double-indirection unless we save enough storage in the working tree. A
+ variation of this is to not record an explicit pointer but instead
+ define an implicit pointer as being to the left-hand-parent tree.
+
+
+Locality of reference
+---------------------
+
+- We should stat files in the same directory without reading or statting
+ files in other directories. That is we should do all the statting we
+ intend to do within a given directory without doing any other IO, to
+ minimise pressure on the drive heads to seek.
+
+- We should read files in the same directory without reading or writing
+ files in other directories - and note this is separate to statting (file
+ data is usually physically disjoint to metadata).
+
+
+Scaling observations
+--------------------
+
+- The stat operation clearly involves every versioned path in the common case.
+- Expanding out the users path selection in a naive manner involves reading the
+ entire tree shape information for both trees and for all pending-merge trees.
+ (Dirstate makes this tolerably cheap for now, but we're still scaling
+ extra-linearly.)
+- The amount of effort required to generate tree differences between the
+ working tree and the basis tree is interesting: with a tree-like structure
+ and some generatable name for child nodes we use the working tree data to
+ eliminate accessing or considering subtrees regardless of historival
+ age. However, if we have had to access the historical tree shape to
+ perform path selection this rather reduces the win we can obtain here.
+ If we can cause path expansion to not require historical shape access
+ (perhaps by performing the expansion after calculating the tree
+ difference for the top level of the selected path) then we can gain a
+ larger win. This strongly suggests that path expansion and tree
+ difference generation should be linked in terms of API.
+
+
+
+..
+ vim: ft=rst tw=74 ai
+
diff --git a/doc/developers/testing.txt b/doc/developers/testing.txt
new file mode 100644
index 0000000..3726ef2
--- /dev/null
+++ b/doc/developers/testing.txt
@@ -0,0 +1,1124 @@
+====================
+Bazaar Testing Guide
+====================
+
+
+The Importance of Testing
+=========================
+
+Reliability is a critical success factor for any version control system.
+We want Bazaar to be highly reliable across multiple platforms while
+evolving over time to meet the needs of its community.
+
+In a nutshell, this is what we expect and encourage:
+
+* New functionality should have test cases. Preferably write the
+ test before writing the code.
+
+ In general, you can test at either the command-line level or the
+ internal API level. See `Writing tests`_ below for more detail.
+
+* Try to practice Test-Driven Development: before fixing a bug, write a
+ test case so that it does not regress. Similarly for adding a new
+ feature: write a test case for a small version of the new feature before
+ starting on the code itself. Check the test fails on the old code, then
+ add the feature or fix and check it passes.
+
+By doing these things, the Bazaar team gets increased confidence that
+changes do what they claim to do, whether provided by the core team or
+by community members. Equally importantly, we can be surer that changes
+down the track do not break new features or bug fixes that you are
+contributing today.
+
+As of September 2009, Bazaar ships with a test suite containing over
+23,000 tests and growing. We are proud of it and want to remain so. As
+community members, we all benefit from it. Would you trust version control
+on your project to a product *without* a test suite like Bazaar has?
+
+
+Running the Test Suite
+======================
+
+As of Bazaar 2.1, you must have the testtools_ library installed to run
+the bzr test suite.
+
+.. _testtools: https://launchpad.net/testtools/
+
+To test all of Bazaar, just run::
+
+ bzr selftest
+
+With ``--verbose`` bzr will print the name of every test as it is run.
+
+This should always pass, whether run from a source tree or an installed
+copy of Bazaar. Please investigate and/or report any failures.
+
+
+Running particular tests
+------------------------
+
+Currently, bzr selftest is used to invoke tests.
+You can provide a pattern argument to run a subset. For example,
+to run just the blackbox tests, run::
+
+ ./bzr selftest -v blackbox
+
+To skip a particular test (or set of tests), use the --exclude option
+(shorthand -x) like so::
+
+ ./bzr selftest -v -x blackbox
+
+To ensure that all tests are being run and succeeding, you can use the
+--strict option which will fail if there are any missing features or known
+failures, like so::
+
+ ./bzr selftest --strict
+
+To list tests without running them, use the --list-only option like so::
+
+ ./bzr selftest --list-only
+
+This option can be combined with other selftest options (like -x) and
+filter patterns to understand their effect.
+
+Once you understand how to create a list of tests, you can use the --load-list
+option to run only a restricted set of tests that you kept in a file, one test
+id by line. Keep in mind that this will never be sufficient to validate your
+modifications, you still need to run the full test suite for that, but using it
+can help in some cases (like running only the failed tests for some time)::
+
+ ./bzr selftest -- load-list my_failing_tests
+
+This option can also be combined with other selftest options, including
+patterns. It has some drawbacks though, the list can become out of date pretty
+quick when doing Test Driven Development.
+
+To address this concern, there is another way to run a restricted set of tests:
+the --starting-with option will run only the tests whose name starts with the
+specified string. It will also avoid loading the other tests and as a
+consequence starts running your tests quicker::
+
+ ./bzr selftest --starting-with bzrlib.blackbox
+
+This option can be combined with all the other selftest options including
+--load-list. The later is rarely used but allows to run a subset of a list of
+failing tests for example.
+
+Disabling plugins
+-----------------
+
+To test only the bzr core, ignoring any plugins you may have installed,
+use::
+
+ ./bzr --no-plugins selftest
+
+Disabling crash reporting
+-------------------------
+
+By default Bazaar uses apport_ to report program crashes. In developing
+Bazaar it's normal and expected to have it crash from time to time, at
+least because a test failed if for no other reason.
+
+Therefore you should probably add ``debug_flags = no_apport`` to your
+``bazaar.conf`` file (in ``~/.bazaar/`` on Unix), so that failures just
+print a traceback rather than writing a crash file.
+
+.. _apport: https://launchpad.net/apport/
+
+
+Test suite debug flags
+----------------------
+
+Similar to the global ``-Dfoo`` debug options, bzr selftest accepts
+``-E=foo`` debug flags. These flags are:
+
+:allow_debug: do *not* clear the global debug flags when running a test.
+ This can provide useful logging to help debug test failures when used
+ with e.g. ``bzr -Dhpss selftest -E=allow_debug``
+
+ Note that this will probably cause some tests to fail, because they
+ don't expect to run with any debug flags on.
+
+
+Using subunit
+-------------
+
+Bazaar can optionally produce output in the machine-readable subunit_
+format, so that test output can be post-processed by various tools. To
+generate a subunit test stream::
+
+ $ ./bzr selftest --subunit
+
+Processing such a stream can be done using a variety of tools including:
+
+* The builtin ``subunit2pyunit``, ``subunit-filter``, ``subunit-ls``,
+ ``subunit2junitxml`` from the subunit project.
+
+* tribunal_, a GUI for showing test results.
+
+* testrepository_, a tool for gathering and managing test runs.
+
+.. _subunit: https://launchpad.net/subunit/
+.. _tribunal: https://launchpad.net/tribunal/
+
+
+Using testrepository
+--------------------
+
+Bazaar ships with a config file for testrepository_. This can be very
+useful for keeping track of failing tests and doing general workflow
+support. To run tests using testrepository::
+
+ $ testr run
+
+To run only failing tests::
+
+ $ testr run --failing
+
+To run only some tests, without plugins::
+
+ $ test run test_selftest -- --no-plugins
+
+See the testrepository documentation for more details.
+
+.. _testrepository: https://launchpad.net/testrepository
+
+
+Babune continuous integration
+-----------------------------
+
+We have a Hudson continuous-integration system that automatically runs
+tests across various platforms. In the future we plan to add more
+combinations including testing plugins. See
+<http://babune.ladeuil.net:24842/>. (Babune = Bazaar Buildbot Network.)
+
+
+Running tests in parallel
+-------------------------
+
+Bazaar can use subunit to spawn multiple test processes. There is
+slightly more chance you will hit ordering or timing-dependent bugs but
+it's much faster::
+
+ $ ./bzr selftest --parallel=fork
+
+Note that you will need the Subunit library
+<https://launchpad.net/subunit/> to use this, which is in
+``python-subunit`` on Ubuntu.
+
+
+Running tests from a ramdisk
+----------------------------
+
+The tests create and delete a lot of temporary files. In some cases you
+can make the test suite run much faster by running it on a ramdisk. For
+example::
+
+ $ sudo mkdir /ram
+ $ sudo mount -t tmpfs none /ram
+ $ TMPDIR=/ram ./bzr selftest ...
+
+You could also change ``/tmp`` in ``/etc/fstab`` to have type ``tmpfs``,
+if you don't mind possibly losing other files in there when the machine
+restarts. Add this line (if there is none for ``/tmp`` already)::
+
+ none /tmp tmpfs defaults 0 0
+
+With a 6-core machine and ``--parallel=fork`` using a tmpfs doubles the
+test execution speed.
+
+
+Writing Tests
+=============
+
+Normally you should add or update a test for all bug fixes or new features
+in Bazaar.
+
+
+Where should I put a new test?
+------------------------------
+
+Bzrlib's tests are organised by the type of test. Most of the tests in
+bzr's test suite belong to one of these categories:
+
+ - Unit tests
+ - Blackbox (UI) tests
+ - Per-implementation tests
+ - Doctests
+
+A quick description of these test types and where they belong in bzrlib's
+source follows. Not all tests fall neatly into one of these categories;
+in those cases use your judgement.
+
+
+Unit tests
+~~~~~~~~~~
+
+Unit tests make up the bulk of our test suite. These are tests that are
+focused on exercising a single, specific unit of the code as directly
+as possible. Each unit test is generally fairly short and runs very
+quickly.
+
+They are found in ``bzrlib/tests/test_*.py``. So in general tests should
+be placed in a file named test_FOO.py where FOO is the logical thing under
+test.
+
+For example, tests for merge3 in bzrlib belong in bzrlib/tests/test_merge3.py.
+See bzrlib/tests/test_sampler.py for a template test script.
+
+
+Blackbox (UI) tests
+~~~~~~~~~~~~~~~~~~~
+
+Tests can be written for the UI or for individual areas of the library.
+Choose whichever is appropriate: if adding a new command, or a new command
+option, then you should be writing a UI test. If you are both adding UI
+functionality and library functionality, you will want to write tests for
+both the UI and the core behaviours. We call UI tests 'blackbox' tests
+and they belong in ``bzrlib/tests/blackbox/*.py``.
+
+When writing blackbox tests please honour the following conventions:
+
+ 1. Place the tests for the command 'name' in
+ bzrlib/tests/blackbox/test_name.py. This makes it easy for developers
+ to locate the test script for a faulty command.
+
+ 2. Use the 'self.run_bzr("name")' utility function to invoke the command
+ rather than running bzr in a subprocess or invoking the
+ cmd_object.run() method directly. This is a lot faster than
+ subprocesses and generates the same logging output as running it in a
+ subprocess (which invoking the method directly does not).
+
+ 3. Only test the one command in a single test script. Use the bzrlib
+ library when setting up tests and when evaluating the side-effects of
+ the command. We do this so that the library api has continual pressure
+ on it to be as functional as the command line in a simple manner, and
+ to isolate knock-on effects throughout the blackbox test suite when a
+ command changes its name or signature. Ideally only the tests for a
+ given command are affected when a given command is changed.
+
+ 4. If you have a test which does actually require running bzr in a
+ subprocess you can use ``run_bzr_subprocess``. By default the spawned
+ process will not load plugins unless ``--allow-plugins`` is supplied.
+
+
+Per-implementation tests
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Per-implementation tests are tests that are defined once and then run
+against multiple implementations of an interface. For example,
+``per_transport.py`` defines tests that all Transport implementations
+(local filesystem, HTTP, and so on) must pass. They are found in
+``bzrlib/tests/per_*/*.py``, and ``bzrlib/tests/per_*.py``.
+
+These are really a sub-category of unit tests, but an important one.
+
+Along the same lines are tests for extension modules. We generally have
+both a pure-python and a compiled implementation for each module. As such,
+we want to run the same tests against both implementations. These can
+generally be found in ``bzrlib/tests/*__*.py`` since extension modules are
+usually prefixed with an underscore. Since there are only two
+implementations, we have a helper function
+``bzrlib.tests.permute_for_extension``, which can simplify the
+``load_tests`` implementation.
+
+
+Doctests
+~~~~~~~~
+
+We make selective use of doctests__. In general they should provide
+*examples* within the API documentation which can incidentally be tested. We
+don't try to test every important case using doctests |--| regular Python
+tests are generally a better solution. That is, we just use doctests to make
+our documentation testable, rather than as a way to make tests. Be aware that
+doctests are not as well isolated as the unit tests, if you need more
+isolation, you're likely want to write unit tests anyway if only to get a
+better control of the test environment.
+
+Most of these are in ``bzrlib/doc/api``. More additions are welcome.
+
+ __ http://docs.python.org/lib/module-doctest.html
+
+There is an `assertDoctestExampleMatches` method in
+`bzrlib.tests.TestCase` that allows you to match against doctest-style
+string templates (including ``...`` to skip sections) from regular Python
+tests.
+
+
+Shell-like tests
+----------------
+
+``bzrlib/tests/script.py`` allows users to write tests in a syntax very
+close to a shell session, using a restricted and limited set of commands
+that should be enough to mimic most of the behaviours.
+
+A script is a set of commands, each command is composed of:
+
+ * one mandatory command line,
+ * one optional set of input lines to feed the command,
+ * one optional set of output expected lines,
+ * one optional set of error expected lines.
+
+Input, output and error lines can be specified in any order.
+
+Except for the expected output, all lines start with a special
+string (based on their origin when used under a Unix shell):
+
+ * '$ ' for the command,
+ * '<' for input,
+ * nothing for output,
+ * '2>' for errors,
+
+Comments can be added anywhere, they start with '#' and end with
+the line.
+
+The execution stops as soon as an expected output or an expected error is not
+matched.
+
+If output occurs and no output is expected, the execution stops and the
+test fails. If unexpected output occurs on the standard error, then
+execution stops and the test fails.
+
+If an error occurs and no expected error is specified, the execution stops.
+
+An error is defined by a returned status different from zero, not by the
+presence of text on the error stream.
+
+The matching is done on a full string comparison basis unless '...' is used, in
+which case expected output/errors can be less precise.
+
+Examples:
+
+The following will succeeds only if 'bzr add' outputs 'adding file'::
+
+ $ bzr add file
+ >adding file
+
+If you want the command to succeed for any output, just use::
+
+ $ bzr add file
+ ...
+ 2>...
+
+or use the ``--quiet`` option::
+
+ $ bzr add -q file
+
+The following will stop with an error::
+
+ $ bzr not-a-command
+
+If you want it to succeed, use::
+
+ $ bzr not-a-command
+ 2> bzr: ERROR: unknown command "not-a-command"
+
+You can use ellipsis (...) to replace any piece of text you don't want to be
+matched exactly::
+
+ $ bzr branch not-a-branch
+ 2>bzr: ERROR: Not a branch...not-a-branch/".
+
+This can be used to ignore entire lines too::
+
+ $ cat
+ <first line
+ <second line
+ <third line
+ # And here we explain that surprising fourth line
+ <fourth line
+ <last line
+ >first line
+ >...
+ >last line
+
+You can check the content of a file with cat::
+
+ $ cat <file
+ >expected content
+
+You can also check the existence of a file with cat, the following will fail if
+the file doesn't exist::
+
+ $ cat file
+
+You can run files containing shell-like scripts with::
+
+ $ bzr test-script <script>
+
+where ``<script>`` is the path to the file containing the shell-like script.
+
+The actual use of ScriptRunner within a TestCase looks something like
+this::
+
+ from bzrlib.tests import script
+
+ def test_unshelve_keep(self):
+ # some setup here
+ script.run_script(self, '''
+ $ bzr add -q file
+ $ bzr shelve -q --all -m Foo
+ $ bzr shelve --list
+ 1: Foo
+ $ bzr unshelve -q --keep
+ $ bzr shelve --list
+ 1: Foo
+ $ cat file
+ contents of file
+ ''')
+
+You can also test commands that read user interaction::
+
+ def test_confirm_action(self):
+ """You can write tests that demonstrate user confirmation"""
+ commands.builtin_command_registry.register(cmd_test_confirm)
+ self.addCleanup(commands.builtin_command_registry.remove, 'test-confirm')
+ self.run_script("""
+ $ bzr test-confirm
+ 2>Really do it? [y/n]:
+ <yes
+ yes
+ """)
+
+To avoid having to specify "-q" for all commands whose output is
+irrelevant, the run_script() method may be passed the keyword argument
+``null_output_matches_anything=True``. For example::
+
+ def test_ignoring_null_output(self):
+ self.run_script("""
+ $ bzr init
+ $ bzr ci -m 'first revision' --unchanged
+ $ bzr log --line
+ 1: ...
+ """, null_output_matches_anything=True)
+
+
+Import tariff tests
+-------------------
+
+`bzrlib.tests.test_import_tariff` has some tests that measure how many
+Python modules are loaded to run some representative commands.
+
+We want to avoid loading code unnecessarily, for reasons including:
+
+* Python modules are interpreted when they're loaded, either to define
+ classes or modules or perhaps to initialize some structures.
+
+* With a cold cache we may incur blocking real disk IO for each module.
+
+* Some modules depend on many others.
+
+* Some optional modules such as `testtools` are meant to be soft
+ dependencies and only needed for particular cases. If they're loaded in
+ other cases then bzr may break for people who don't have those modules.
+
+`test_import_tariff` allows us to check that removal of imports doesn't
+regress.
+
+This is done by running the command in a subprocess with
+``PYTHON_VERBOSE=1``. Starting a whole Python interpreter is pretty slow,
+so we don't want exhaustive testing here, but just enough to guard against
+distinct fixed problems.
+
+Assertions about precisely what is loaded tend to be brittle so we instead
+make assertions that particular things aren't loaded.
+
+Unless selftest is run with ``--no-plugins``, modules will be loaded in
+the usual way and checks made on what they cause to be loaded. This is
+probably worth checking into, because many bzr users have at least some
+plugins installed (and they're included in binary installers).
+
+In theory, plugins might have a good reason to load almost anything:
+someone might write a plugin that opens a network connection or pops up a
+gui window every time you run 'bzr status'. However, it's more likely
+that the code to do these things is just being loaded accidentally. We
+might eventually need to have a way to make exceptions for particular
+plugins.
+
+Some things to check:
+
+* non-GUI commands shouldn't load GUI libraries
+
+* operations on bzr native formats sholudn't load foreign branch libraries
+
+* network code shouldn't be loaded for purely local operations
+
+* particularly expensive Python built-in modules shouldn't be loaded
+ unless there is a good reason
+
+
+Testing locking behaviour
+-------------------------
+
+In order to test the locking behaviour of commands, it is possible to install
+a hook that is called when a write lock is: acquired, released or broken.
+(Read locks also exist, they cannot be discovered in this way.)
+
+A hook can be installed by calling bzrlib.lock.Lock.hooks.install_named_hook.
+The three valid hooks are: `lock_acquired`, `lock_released` and `lock_broken`.
+
+Example::
+
+ locks_acquired = []
+ locks_released = []
+
+ lock.Lock.hooks.install_named_hook('lock_acquired',
+ locks_acquired.append, None)
+ lock.Lock.hooks.install_named_hook('lock_released',
+ locks_released.append, None)
+
+`locks_acquired` will now receive a LockResult instance for all locks acquired
+since the time the hook is installed.
+
+The last part of the `lock_url` allows you to identify the type of object that is locked.
+
+- BzrDir: `/branch-lock`
+- Working tree: `/checkout/lock`
+- Branch: `/branch/lock`
+- Repository: `/repository/lock`
+
+To test if a lock is a write lock on a working tree, one can do the following::
+
+ self.assertEndsWith(locks_acquired[0].lock_url, "/checkout/lock")
+
+See bzrlib/tests/commands/test_revert.py for an example of how to use this for
+testing locks.
+
+
+Skipping tests
+--------------
+
+In our enhancements to unittest we allow for some addition results beyond
+just success or failure.
+
+If a test can't be run, it can say that it's skipped by raising a special
+exception. This is typically used in parameterized tests |--| for example
+if a transport doesn't support setting permissions, we'll skip the tests
+that relating to that. ::
+
+ try:
+ return self.branch_format.initialize(repo.bzrdir)
+ except errors.UninitializableFormat:
+ raise tests.TestSkipped('Uninitializable branch format')
+
+Raising TestSkipped is a good idea when you want to make it clear that the
+test was not run, rather than just returning which makes it look as if it
+was run and passed.
+
+Several different cases are distinguished:
+
+TestSkipped
+ Generic skip; the only type that was present up to bzr 0.18.
+
+TestNotApplicable
+ The test doesn't apply to the parameters with which it was run.
+ This is typically used when the test is being applied to all
+ implementations of an interface, but some aspects of the interface
+ are optional and not present in particular concrete
+ implementations. (Some tests that should raise this currently
+ either silently return or raise TestSkipped.) Another option is
+ to use more precise parameterization to avoid generating the test
+ at all.
+
+UnavailableFeature
+ The test can't be run because a dependency (typically a Python
+ library) is not available in the test environment. These
+ are in general things that the person running the test could fix
+ by installing the library. It's OK if some of these occur when
+ an end user runs the tests or if we're specifically testing in a
+ limited environment, but a full test should never see them.
+
+ See `Test feature dependencies`_ below.
+
+KnownFailure
+ The test exists but is known to fail, for example this might be
+ appropriate to raise if you've committed a test for a bug but not
+ the fix for it, or if something works on Unix but not on Windows.
+
+ Raising this allows you to distinguish these failures from the
+ ones that are not expected to fail. If the test would fail
+ because of something we don't expect or intend to fix,
+ KnownFailure is not appropriate, and TestNotApplicable might be
+ better.
+
+ KnownFailure should be used with care as we don't want a
+ proliferation of quietly broken tests.
+
+
+
+We plan to support three modes for running the test suite to control the
+interpretation of these results. Strict mode is for use in situations
+like merges to the mainline and releases where we want to make sure that
+everything that can be tested has been tested. Lax mode is for use by
+developers who want to temporarily tolerate some known failures. The
+default behaviour is obtained by ``bzr selftest`` with no options, and
+also (if possible) by running under another unittest harness.
+
+======================= ======= ======= ========
+result strict default lax
+======================= ======= ======= ========
+TestSkipped pass pass pass
+TestNotApplicable pass pass pass
+UnavailableFeature fail pass pass
+KnownFailure fail pass pass
+======================= ======= ======= ========
+
+
+Test feature dependencies
+-------------------------
+
+Writing tests that require a feature
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Rather than manually checking the environment in each test, a test class
+can declare its dependence on some test features. The feature objects are
+checked only once for each run of the whole test suite.
+
+(For historical reasons, as of May 2007 many cases that should depend on
+features currently raise TestSkipped.)
+
+For example::
+
+ class TestStrace(TestCaseWithTransport):
+
+ _test_needs_features = [StraceFeature]
+
+This means all tests in this class need the feature. If the feature is
+not available the test will be skipped using UnavailableFeature.
+
+Individual tests can also require a feature using the ``requireFeature``
+method::
+
+ self.requireFeature(StraceFeature)
+
+The old naming style for features is CamelCase, but because they're
+actually instances not classses they're now given instance-style names
+like ``apport``.
+
+Features already defined in ``bzrlib.tests`` and ``bzrlib.tests.features``
+include:
+
+ - apport
+ - paramiko
+ - SymlinkFeature
+ - HardlinkFeature
+ - OsFifoFeature
+ - UnicodeFilenameFeature
+ - FTPServerFeature
+ - CaseInsensitiveFilesystemFeature.
+ - chown_feature: The test can rely on OS being POSIX and python
+ supporting os.chown.
+ - posix_permissions_feature: The test can use POSIX-style
+ user/group/other permission bits.
+
+
+Defining a new feature that tests can require
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+New features for use with ``_test_needs_features`` or ``requireFeature``
+are defined by subclassing ``bzrlib.tests.Feature`` and overriding the
+``_probe`` and ``feature_name`` methods. For example::
+
+ class _SymlinkFeature(Feature):
+
+ def _probe(self):
+ return osutils.has_symlinks()
+
+ def feature_name(self):
+ return 'symlinks'
+
+ SymlinkFeature = _SymlinkFeature()
+
+A helper for handling running tests based on whether a python
+module is available. This can handle 3rd-party dependencies (is
+``paramiko`` available?) as well as stdlib (``termios``) or
+extension modules (``bzrlib._groupcompress_pyx``). You create a
+new feature instance with::
+
+ # in bzrlib/tests/features.py
+ apport = tests.ModuleAvailableFeature('apport')
+
+
+ # then in bzrlib/tests/test_apport.py
+ class TestApportReporting(TestCaseInTempDir):
+
+ _test_needs_features = [features.apport]
+
+
+Testing translations
+-----------------------
+
+Translations are disabled by default in tests. If you want to test
+that code is translated you can use the ``ZzzTranslations`` class from
+``test_i18n``::
+
+ self.overrideAttr(i18n, '_translations', ZzzTranslations())
+
+And check the output strings look like ``u"zz\xe5{{output}}"``.
+
+To test the gettext setup and usage you override i18n.installed back
+to self.i18nInstalled and _translations to None, see
+test_i18n.TestInstall.
+
+
+Testing deprecated code
+-----------------------
+
+When code is deprecated, it is still supported for some length of time,
+usually until the next major version. The ``applyDeprecated`` helper
+wraps calls to deprecated code to verify that it is correctly issuing the
+deprecation warning, and also prevents the warnings from being printed
+during test runs.
+
+Typically patches that apply the ``@deprecated_function`` decorator should
+update the accompanying tests to use the ``applyDeprecated`` wrapper.
+
+``applyDeprecated`` is defined in ``bzrlib.tests.TestCase``. See the API
+docs for more details.
+
+
+Testing exceptions and errors
+-----------------------------
+
+It's important to test handling of errors and exceptions. Because this
+code is often not hit in ad-hoc testing it can often have hidden bugs --
+it's particularly common to get NameError because the exception code
+references a variable that has since been renamed.
+
+.. TODO: Something about how to provoke errors in the right way?
+
+In general we want to test errors at two levels:
+
+1. A test in ``test_errors.py`` checking that when the exception object is
+ constructed with known parameters it produces an expected string form.
+ This guards against mistakes in writing the format string, or in the
+ ``str`` representations of its parameters. There should be one for
+ each exception class.
+
+2. Tests that when an api is called in a particular situation, it raises
+ an error of the expected class. You should typically use
+ ``assertRaises``, which in the Bazaar test suite returns the exception
+ object to allow you to examine its parameters.
+
+In some cases blackbox tests will also want to check error reporting. But
+it can be difficult to provoke every error through the commandline
+interface, so those tests are only done as needed |--| eg in response to a
+particular bug or if the error is reported in an unusual way(?) Blackbox
+tests should mostly be testing how the command-line interface works, so
+should only test errors if there is something particular to the cli in how
+they're displayed or handled.
+
+
+Testing warnings
+----------------
+
+The Python ``warnings`` module is used to indicate a non-fatal code
+problem. Code that's expected to raise a warning can be tested through
+callCatchWarnings.
+
+The test suite can be run with ``-Werror`` to check no unexpected errors
+occur.
+
+However, warnings should be used with discretion. It's not an appropriate
+way to give messages to the user, because the warning is normally shown
+only once per source line that causes the problem. You should also think
+about whether the warning is serious enought that it should be visible to
+users who may not be able to fix it.
+
+
+Interface implementation testing and test scenarios
+---------------------------------------------------
+
+There are several cases in Bazaar of multiple implementations of a common
+conceptual interface. ("Conceptual" because it's not necessary for all
+the implementations to share a base class, though they often do.)
+Examples include transports and the working tree, branch and repository
+classes.
+
+In these cases we want to make sure that every implementation correctly
+fulfils the interface requirements. For example, every Transport should
+support the ``has()`` and ``get()`` and ``clone()`` methods. We have a
+sub-suite of tests in ``test_transport_implementations``. (Most
+per-implementation tests are in submodules of ``bzrlib.tests``, but not
+the transport tests at the moment.)
+
+These tests are repeated for each registered Transport, by generating a
+new TestCase instance for the cross product of test methods and transport
+implementations. As each test runs, it has ``transport_class`` and
+``transport_server`` set to the class it should test. Most tests don't
+access these directly, but rather use ``self.get_transport`` which returns
+a transport of the appropriate type.
+
+The goal is to run per-implementation only the tests that relate to that
+particular interface. Sometimes we discover a bug elsewhere that happens
+with only one particular transport. Once it's isolated, we can consider
+whether a test should be added for that particular implementation,
+or for all implementations of the interface.
+
+See also `Per-implementation tests`_ (above).
+
+
+Test scenarios and variations
+-----------------------------
+
+Some utilities are provided for generating variations of tests. This can
+be used for per-implementation tests, or other cases where the same test
+code needs to run several times on different scenarios.
+
+The general approach is to define a class that provides test methods,
+which depend on attributes of the test object being pre-set with the
+values to which the test should be applied. The test suite should then
+also provide a list of scenarios in which to run the tests.
+
+A single *scenario* is defined by a `(name, parameter_dict)` tuple. The
+short string name is combined with the name of the test method to form the
+test instance name. The parameter dict is merged into the instance's
+attributes.
+
+For example::
+
+ load_tests = load_tests_apply_scenarios
+
+ class TestCheckout(TestCase):
+
+ scenarios = multiply_scenarios(
+ VaryByRepositoryFormat(),
+ VaryByTreeFormat(),
+ )
+
+The `load_tests` declaration or definition should be near the top of the
+file so its effect can be seen.
+
+
+Test support
+------------
+
+We have a rich collection of tools to support writing tests. Please use
+them in preference to ad-hoc solutions as they provide portability and
+performance benefits.
+
+
+TestCase and its subclasses
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``bzrlib.tests`` module defines many TestCase classes to help you
+write your tests.
+
+TestCase
+ A base TestCase that extends the Python standard library's
+ TestCase in several ways. TestCase is build on
+ ``testtools.TestCase``, which gives it support for more assertion
+ methods (e.g. ``assertContainsRe``), ``addCleanup``, and other
+ features (see its API docs for details). It also has a ``setUp`` that
+ makes sure that global state like registered hooks and loggers won't
+ interfere with your test. All tests should use this base class
+ (whether directly or via a subclass). Note that we are trying not to
+ add more assertions at this point, and instead to build up a library
+ of ``bzrlib.tests.matchers``.
+
+TestCaseWithMemoryTransport
+ Extends TestCase and adds methods like ``get_transport``,
+ ``make_branch`` and ``make_branch_builder``. The files created are
+ stored in a MemoryTransport that is discarded at the end of the test.
+ This class is good for tests that need to make branches or use
+ transports, but that don't require storing things on disk. All tests
+ that create bzrdirs should use this base class (either directly or via
+ a subclass) as it ensures that the test won't accidentally operate on
+ real branches in your filesystem.
+
+TestCaseInTempDir
+ Extends TestCaseWithMemoryTransport. For tests that really do need
+ files to be stored on disk, e.g. because a subprocess uses a file, or
+ for testing functionality that accesses the filesystem directly rather
+ than via the Transport layer (such as dirstate).
+
+TestCaseWithTransport
+ Extends TestCaseInTempDir. Provides ``get_url`` and
+ ``get_readonly_url`` facilities. Subclasses can control the
+ transports used by setting ``vfs_transport_factory``,
+ ``transport_server`` and/or ``transport_readonly_server``.
+
+
+See the API docs for more details.
+
+
+BranchBuilder
+~~~~~~~~~~~~~
+
+When writing a test for a feature, it is often necessary to set up a
+branch with a certain history. The ``BranchBuilder`` interface allows the
+creation of test branches in a quick and easy manner. Here's a sample
+session::
+
+ builder = self.make_branch_builder('relpath')
+ builder.build_commit()
+ builder.build_commit()
+ builder.build_commit()
+ branch = builder.get_branch()
+
+``make_branch_builder`` is a method of ``TestCaseWithMemoryTransport``.
+
+Note that many current tests create test branches by inheriting from
+``TestCaseWithTransport`` and using the ``make_branch_and_tree`` helper to
+give them a ``WorkingTree`` that they can commit to. However, using the
+newer ``make_branch_builder`` helper is preferred, because it can build
+the changes in memory, rather than on disk. Tests that are explictly
+testing how we work with disk objects should, of course, use a real
+``WorkingTree``.
+
+Please see bzrlib.branchbuilder for more details.
+
+If you're going to examine the commit timestamps e.g. in a test for log
+output, you should set the timestamp on the tree, rather than using fuzzy
+matches in the test.
+
+
+TreeBuilder
+~~~~~~~~~~~
+
+The ``TreeBuilder`` interface allows the construction of arbitrary trees
+with a declarative interface. A sample session might look like::
+
+ tree = self.make_branch_and_tree('path')
+ builder = TreeBuilder()
+ builder.start_tree(tree)
+ builder.build(['foo', "bar/", "bar/file"])
+ tree.commit('commit the tree')
+ builder.finish_tree()
+
+Usually a test will create a tree using ``make_branch_and_memory_tree`` (a
+method of ``TestCaseWithMemoryTransport``) or ``make_branch_and_tree`` (a
+method of ``TestCaseWithTransport``).
+
+Please see bzrlib.treebuilder for more details.
+
+PreviewTree
+~~~~~~~~~~~
+
+PreviewTrees are based on TreeTransforms. This means they can represent
+virtually any state that a WorkingTree can have, including unversioned files.
+They can be used to test the output of anything that produces TreeTransforms,
+such as merge algorithms and revert. They can also be used to test anything
+that takes arbitrary Trees as its input.
+
+::
+
+ # Get an empty tree to base the transform on.
+ b = self.make_branch('.')
+ empty_tree = b.repository.revision_tree(_mod_revision.NULL_REVISION)
+ tt = TransformPreview(empty_tree)
+ self.addCleanup(tt.finalize)
+ # Empty trees don't have a root, so add it first.
+ root = tt.new_directory('', ROOT_PARENT, 'tree-root')
+ # Set the contents of a file.
+ tt.new_file('new-file', root, 'contents', 'file-id')
+ preview = tt.get_preview_tree()
+ # Test the contents.
+ self.assertEqual('contents', preview.get_file_text('file-id'))
+
+PreviewTrees can stack, with each tree falling back to the previous::
+
+ tt2 = TransformPreview(preview)
+ self.addCleanup(tt2.finalize)
+ tt2.new_file('new-file2', tt2.root, 'contents2', 'file-id2')
+ preview2 = tt2.get_preview_tree()
+ self.assertEqual('contents', preview2.get_file_text('file-id'))
+ self.assertEqual('contents2', preview2.get_file_text('file-id2'))
+
+
+Temporarily changing state
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If your test needs to temporarily mutate some global state, and you need
+it restored at the end, you can say for example::
+
+ self.overrideAttr(osutils, '_cached_user_encoding', 'latin-1')
+
+This should be used with discretion; sometimes it's better to make the
+underlying code more testable so that you don't need to rely on monkey
+patching.
+
+
+Observing calls to a function
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes it's useful to observe how a function is called, typically when
+calling it has side effects but the side effects are not easy to observe
+from a test case. For instance the function may be expensive and we want
+to assert it is not called too many times, or it has effects on the
+machine that are safe to run during a test but not easy to measure. In
+these cases, you can use `recordCalls` which will monkey-patch in a
+wrapper that records when the function is called.
+
+
+Temporarily changing environment variables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If yout test needs to temporarily change some environment variable value
+(which generally means you want it restored at the end), you can use::
+
+ self.overrideEnv('BZR_ENV_VAR', 'new_value')
+
+If you want to remove a variable from the environment, you should use the
+special ``None`` value::
+
+ self.overrideEnv('PATH', None)
+
+If you add a new feature which depends on a new environment variable, make
+sure it behaves properly when this variable is not defined (if applicable) and
+if you need to enforce a specific default value, check the
+``TestCase._cleanEnvironment`` in ``bzrlib.tests.__init__.py`` which defines a
+proper set of values for all tests.
+
+Cleaning up
+~~~~~~~~~~~
+
+Our base ``TestCase`` class provides an ``addCleanup`` method, which
+should be used instead of ``tearDown``. All the cleanups are run when the
+test finishes, regardless of whether it passes or fails. If one cleanup
+fails, later cleanups are still run.
+
+(The same facility is available outside of tests through
+``bzrlib.cleanup``.)
+
+
+Manual testing
+==============
+
+Generally we prefer automated testing but sometimes a manual test is the
+right thing, especially for performance tests that want to measure elapsed
+time rather than effort.
+
+Simulating slow networks
+------------------------
+
+To get realistically slow network performance for manually measuring
+performance, we can simulate 500ms latency (thus 1000ms round trips)::
+
+ $ sudo tc qdisc add dev lo root netem delay 500ms
+
+Normal system behaviour is restored with ::
+
+ $ sudo tc qdisc del dev lo root
+
+A more precise version that only filters traffic to port 4155 is::
+
+ tc qdisc add dev lo root handle 1: prio
+ tc qdisc add dev lo parent 1:3 handle 30: netem delay 500ms
+ tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip dport 4155 0xffff flowid 1:3
+ tc filter add dev lo protocol ip parent 1:0 prio 3 u32 match ip sport 4155 0xffff flowid 1:3
+
+and to remove this::
+
+ tc filter del dev lo protocol ip parent 1: pref 3 u32
+ tc qdisc del dev lo root handle 1:
+
+You can use similar code to add additional delay to a real network
+interface, perhaps only when talking to a particular server or pointing at
+a VM. For more information see <http://lartc.org/>.
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai et sw=4
diff --git a/doc/developers/tortoise-strategy.txt b/doc/developers/tortoise-strategy.txt
new file mode 100644
index 0000000..0f8750d
--- /dev/null
+++ b/doc/developers/tortoise-strategy.txt
@@ -0,0 +1,463 @@
+Bazaar Windows Shell Extension Options
+======================================
+
+.. contents:: :local:
+
+Introduction
+------------
+
+This document details the implementation strategy chosen for the
+Bazaar Windows Shell Extensions, otherwise known as TortoiseBzr, or TBZR.
+As justification for the strategy, it also describes the general architecture
+of Windows Shell Extensions, then looks at the C++ implemented TortoiseSvn
+and the Python implemented TortoiseBzr, and discusses alternative
+implementation strategies, and the reasons they were not chosen.
+
+The following points summarize the strategy:
+
+* Main shell extension code will be implemented in C++, and be as thin as
+ possible. It will not directly do any VCS work, but instead will perform
+ all operations via either external applications or an RPC server.
+
+* Most VCS operations will be performed by external applications. For
+ example, committing changes or viewing history will spawn a child
+ process that provides its own UI.
+
+* For operations where spawning a child process is not practical, an
+ external RPC server will be implemented in Python and will directly use
+ the VCS library. In the short term, there will be no attempt to create a
+ general purpose RPC mechanism, but instead will be focused on keeping the
+ C++ RPC client as thin, fast and dumb as possible.
+
+Background Information
+----------------------
+
+The facts about shell extensions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Well - the facts as I understand them :)
+
+Shell Extensions are COM objects. They are implemented as DLLs which are
+loaded by the Windows shell. There is no facility for shell extensions to
+exist in a separate process - DLLs are the only option, and they are loaded
+into other processes which take advantage of the Windows shell (although
+obviously this DLL is free to do whatever it likes).
+
+For the sake of this discussion, there are 2 categories of shell extensions:
+
+* Ones that create a new "namespace". The file-system itself is an example of
+ such a namespace, as is the "Recycle Bin". For a user-created example,
+ picture a new tree under "My Computer" which allows you to browse a remote
+ server - it creates a new, stand-alone tree that doesn't really interact
+ with the existing namespaces.
+
+* Ones that enhance existing namespaces, including the filesystem. An example
+ would be an extension which uses Icon Overlays to modify how existing files
+ on disk are displayed or add items to their context menu, for example.
+
+The latter category is the kind of shell extension relevant for TortoiseBzr,
+and it has an important implication - it will be pulled into any process
+which uses the shell to display a list of files. While this is somewhat
+obvious for Windows Explorer (which many people consider the shell), every
+other process that shows a FileOpen/FileSave dialog will have these shell
+extensions loaded into its process space. This may surprise many people - the
+simple fact of allowing the user to select a filename will result in an
+unknown number of DLLs being loaded into your process. For a concrete
+example, when notepad.exe first starts with an empty file it is using around
+3.5MB of RAM. As soon as the FileOpen dialog is loaded, TortoiseSvn loads
+well over 20 additional DLLs, including the MSVC8 runtime, into the Notepad
+process causing its memory usage (as reported by task manager) to more than
+double - all without doing anything tortoise specific at all. (In fairness,
+this illustration is contrived - the code from these DLLs are already in
+memory and there is no reason to suggest TSVN adds any other unreasonable
+burden - but the general point remains valid.)
+
+This has wide-ranging implications. It means that such shell extensions
+should be developed using a tool which can never cause conflict with
+arbitrary processes. For this very reason, MS recommend against using .NET
+to write shell extensions[1], as there is a significant risk of being loaded
+into a process that uses a different version of the .NET runtime, and this
+will kill the process. Similarly, Python implemented shell extension may well
+conflict badly with other Python implemented applications (and will certainly
+kill them in some situations). A similar issue exists with GUI toolkits used
+- using (say) PyGTK directly in the shell extension would need to be avoided
+(which it currently is best I can tell). It should also be obvious that the
+shell extension will be in many processes simultaneously, meaning use of a
+simple log-file (for example) is problematic.
+
+In practice, there is only 1 truly safe option - a low-level language (such
+as C/C++) which makes use of only the win32 API, and a static version of the
+C runtime library if necessary. Obviously, this sucks from our POV. :)
+
+[1]: http://blogs.msdn.com/oldnewthing/archive/2006/12/18/1317290.aspx
+
+Analysis of TortoiseSVN code
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TortoiseSVN is implemented in C++. It relies on an external process to
+perform most UI (such as diff, log, commit etc.) commands, but it appears to
+directly embed the SVN C libraries for the purposes of obtaining status for
+icon overlays, context menu, drag&drop, etc.
+
+The use of an external process to perform commands is fairly simplistic in
+terms of parent and modal windows. For example, when selecting "Commit", a
+new process starts and *usually* ends up as the foreground window, but it may
+occasionally be lost underneath the window which created it, and the user may
+accidently start many processes when they only need 1. Best I can tell, this
+isn't necessarily a limitation of the approach, just the implementation.
+
+Advantages of using the external process is that it keeps all the UI code
+outside Windows explorer - only the minimum needed to perform operations
+directly needed by the shell are part of the "shell extension" and the rest
+of TortoiseSvn is "just" a fairly large GUI application implementing many
+commands. The command-line to the app has even been documented for people who
+wish to automate tasks using that GUI. This GUI is also implemented in C++
+using Windows resource files.
+
+TortoiseSvn has an option (enabled by default) which enabled a cache using a
+separate process, aptly named TSVNCache.exe. It uses a named pipe to accept
+connections from other processes for various operations. When enabled, TSVN
+fetches most (all?) status information from this process, but it also has the
+option to talk directly to the VCS, along with options to disable functionality
+in various cases.
+
+There doesn't seem to be a good story for logging or debugging - which is
+what you expect from C++ based apps. :( Most of the heavy lifting is done by
+the external application, which might offer better facilities.
+
+Analysis of existing TortoiseBzr code
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The existing code is actually quite cool given its history (SoC student,
+etc), so this should not be taken as criticism of the implementer nor of the
+implementation. Indeed, many criticisms are also true of the TortoiseSvn
+implementation - see above. However, I have attempted to list the bad things
+rather than the good things so a clear future strategy can be agreed, with
+all limitations understood.
+
+The existing TortoiseBzr code has been ported into Python from other tortoise
+implementations (probably svn). This means it is very nice to implement and
+develop, but suffers the problems described above - it is likely to conflict
+with other Python based processes, and it means the entire CPython runtime
+and libraries are pulled into many arbitrary processes.
+
+The existing TortoiseBzr code pulls in the bzrlib library to determine the
+path of the bzr library, and also to determine the status of files, but uses
+an external process for most GUI commands - ie, very similar to TortoiseSvn
+as described above - and as such, all comments above apply equally here - but
+note that the bzr library *is* pulled into the shell, and therefore every
+application using the shell. The GUI in the external application is written
+in PyGTK, which may not offer the best Windows "look and feel", but that
+discussion is beyond the scope of this document.
+
+It has a better story for logging and debugging for the developer - but not
+for diagnosing issues in the field - although again, much of the heavy
+lifting remains done by the external application.
+
+It uses a rudimentary in-memory cache for the status of files and
+directories, the implementation of which isn't really suitable (ie, no
+theoretical upper bound on cache size), and also means that there is no
+sharing of cached information between processes, which is unfortunate (eg,
+imagine a user using Windows explorer, then switching back to their editor)
+and also error prone (it's possible the editor will check the file in,
+meaning Windows explorer will be showing stale data). This may be possible to
+address via file-system notifications, but a shared cache would be preferred
+(although clearly more difficult to implement).
+
+One tortoise port recently announced a technique for all tortoise ports to
+share the same icon overlays to help work around a limitation in Windows on
+the total number of overlays (it's limited to 15, due to the number of bits
+reserved in a 32bit int for overlays). TBZR needs to take advantage of that
+(but to be fair, this overlay sharing technique was probably done after the
+TBZR implementation).
+
+The current code appears to recursively walk a tree to check if *any* file in
+the tree has changed, so it can reflect this in the parent directory status.
+This is almost certainly an evil thing to do (Shell Extensions are optimized
+so that a folder doesn't even need to look in its direct children for another
+folder, let alone recurse for any reason at all. It may be a network mounted
+drive that doesn't perform at all.)
+
+Although somewhat dependent on bzr itself, we need a strategy for binary
+releases (ie, it assumes python.exe, etc) and integration into an existing
+"blessed" installer.
+
+Trivially, the code is not PEP8 compliant and was written by someone fairly
+inexperienced with the language.
+
+Detailed Implementation Strategy
+--------------------------------
+
+We will create a hybrid Python and C++ implementation. In this model, we
+would still use something like TSVNCache.exe (this external
+process doesn't have the same restrictions as the shell extension itself) but
+go one step further - use this remote process for *all* interactions with
+bzr, including status and other "must be fast" operations. This would allow
+the shell extension itself to be implemented in C++, but still take advantage
+of Python for much of the logic.
+
+A pragmatic implementation strategy will be used to work towards the above
+infrastructure - we will keep the shell extension implemented in Python - but
+without using bzrlib. This allows us to focus on this
+shared-cache/remote-process infrastructure without immediately
+re-implementing a shell extension in C++. Longer term, once the
+infrastructure is in place and as optimized as possible, we can move to C++
+code in the shell calling our remote Python process. This port should try and
+share as much code as possible from TortoiseSvn, including overlay handlers.
+
+External Command Processor
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The external command application (ie, the app invoked by the shell extension
+to perform commands) can remain as-is, and remain a "shell" for other
+external commands. The implementation of this application is not particularly
+relevant to the shell extension, just the interface to the application (ie,
+its command-line) is. In the short term this will remain PyGTK and will only
+change if there is compelling reason - cross-platform GUI tools are a better
+for bazaar than Windows specific ones, although native look-and-feel is
+important. Either way, this can change independently from the shell
+extension.
+
+Performance considerations
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As discussed above, the model used by Tortoise is that most "interesting"
+things are done by external applications. Most Tortoise implementations
+show read-only columns in the "detail" view, and shows a few read only
+properties in the "Properties" dialog - but most of these properties are
+"state" related (eg, revision number), or editing of others is done by
+launching an external application. This means that the shell extension itself
+really has 2 basic requirements WRT RPC: 1) get the local state of a file and
+2) get some named state-related "properties" for a file. Everything else can
+be built on that.
+
+There are 2 aspects of the shell integration which are performance critical -
+the "icon overlays" and "column providers".
+
+The short-story with Icon Overlays is that we need to register 12 global
+"overlay providers" - one for each state we show. Each provider is called for
+every icon ever shown in Windows explorer or in any application's FileOpen
+dialog. While most versions of Windows update icons in the background, we
+still need to perform well. On the positive side, this just needs the simple
+"local state" of a file - information that can probably be carried in a
+single byte. On the negative side, it is the shell which makes a synchronous
+call to us with a single filename as an arg, which makes it difficult to
+"batch" multiple status requests into a single RPC call.
+
+The story with columns is messier - these have changed significantly for
+Vista and the new system may not work with the VCS model (see below).
+However, if we implement this, it will be fairly critical to have
+high-performance name/value pairs implemented, as described above.
+
+Note that the nature of the shell implementation means we will have a large
+number of "unrelated" handlers, each called somewhat independently by the
+shell, often for information about the same file (eg, imagine each of our
+overlay providers all called in turn with the same filename, followed by our
+column providers called in turn with the same filename. However, that isn't
+exactly what happens!). This means we will need a kind of cache, geared
+towards reducing the number of status or property requests we make to the RPC
+server.
+
+We will also allow all of the above to be disabled via user preferences.
+Thus, Icon Overlays could be disabled if it did cause a problem for some
+people, for example.
+
+RPC options
+~~~~~~~~~~~
+
+Due to the high number of calls for icon overlays, the RPC overhead must be
+kept as low as possible. Due to the client side being implemented in C++,
+reducing complexity is also a goal. Our requirements are quite simple and no
+existing RPC options exist we can leverage. It does not seen prudent to build
+an XMLRPC solution for tbzr - which is not to preclude the use of such a
+server in the future, but tbzr need not become the "pilot" project for an
+XMLRPC server given these constraints.
+
+I propose that a custom RPC mechanism, built initially using windows-specific
+named-pipes, be used. A binary format, designed with an eye towards
+implementation speed and C++ simplicity, will be used. If we succeed here, we
+can build on that infrastructure, and even replace it should other more
+general frameworks materialize.
+
+FWIW, with a Python process at each end, my P4 2.4G machine can achieve
+around 25000 "calls" per-second across an open named pipe. C++ at one end
+should increase this a little, but obviously any real work done by the Python
+side of the process will be the bottle-neck. However, this throughput would
+appear sufficient to implement a prototype.
+
+Vista versus XP
+~~~~~~~~~~~~~~~
+
+Let's try and avoid an OS advocacy debate :) But it is probably true that
+TBZR will, over its life, be used by more Vista computers than XP ones. In
+short, Vista has changed a number of shell related interfaces, and while TSVN
+is slowly catching up (http://tortoisesvn.net/vistaproblems) they are a pain.
+
+XP has IColumnProvider (as implemented by Tortoise), but Vista changes this
+model. The new model is based around "file types" (eg, .jpg files) and it
+appears each file type can only have 1 provider! TSVN also seems to think the
+Vista model isn't going to work (see previous link). It's not clear how much
+effort we should expend on a column system that has already been abandoned by
+MS. I would argue we spend effort on other parts of the system (ie, the
+external GUI apps themselves, etc) and see if a path forward does emerge for
+Vista. We can re-evaluate this based on user feedback and more information
+about features of the Vista property system.
+
+Reuse of TSVNCache?
+~~~~~~~~~~~~~~~~~~~
+
+The RPC mechanism and the tasks performed by the RPC server (RPC, file system
+crawling and watching, device notifications, caching) are very similar to
+those already implemented for TSVN and analysis of that code shows that
+it is not particularly tied to any VCS model. As a result, consideration
+should be given to making the best use of this existing debugged and
+optimized technology.
+
+Discussions with the TSVN developers have indicated that they would prefer us
+to fork their code rather than introduce complexity and instability into
+their code by attempting to share it. See the follow-ups to
+http://thread.gmane.org/gmane.comp.version-control.subversion.tortoisesvn.devel/32635/focus=32651
+for details.
+
+For background, the TSVNCache process is fairly sophisticated - but mainly in
+areas not related to source control. It has had various performance tweaks
+and is smart in terms of minimizing its use of resources when possible. The
+'cloc' utility counts ~5000 lines of C++ code and weighs in just under 200KB
+on disk (not including headers), so this is not a trivial application.
+However, the code that is of most interest (the crawlers, watchers and cache)
+are roughly ~2500 lines of C++. Most of the source files only depend lightly
+on SVN specifics, so it would not be a huge job to make the existing code
+talk to Bazaar. The code is thread-safe, but not particularly thread-friendly
+(ie, fairly coarse-grained locks are taken in most cases).
+
+In practice, this give us 2 options - "fork" or "port":
+
+* Fork the existing C++ code, replacing the existing source-control code with
+ code that talks to Bazaar. This would involve introducing a Python layer,
+ but only at the layers where we need to talk to bzrlib. The bulk of the
+ code would remain in C++.
+
+ This would have the following benefits:
+
+ - May offer significant performance advantages in some cases (eg, a
+ cache-hit would never enter Python at all.)
+
+ - Quickest time to a prototype working - the existing working code can be
+ used quicker.
+
+ And the following drawbacks:
+
+ - More complex to develop. People wishing to hack on it must be on Windows,
+ know C++ and own the most recent MSVC8.
+
+ - More complex to build and package: people making binaries must be on
+ Windows and have the most recent MSVC8.
+
+ - Is tied to Windows - it would be impractical for this to be
+ cross-platform, even just for test purposes (although parts of it
+ obviously could).
+
+* Port the existing C++ code to Python. We would do this almost
+ "line-for-line", and attempt to keep many optimizations in place (or at
+ least document what the optimizations were for ones we consider dubious).
+ For the windows versions, pywin32 and ctypes would be leaned on - there
+ would be no C++ at all.
+
+ This would have the following benefits:
+
+ - Only need Python and Python skills to hack on it.
+
+ - No C++ compiler needed means easier to cut releases
+
+ - Python makes it easier to understand and maintain - it should appear much
+ less complex than the C++ version.
+
+ And the following drawbacks:
+
+ - Will be slower in some cases - eg, a cache-hit will involve executing
+ Python code.
+
+ - Will take longer to get a minimal system working. In practice this
+ probably means the initial versions will not be as sophisticated.
+
+Given the above, there are two issues which prevent Python being the clear
+winner: (1) will it perform OK? (2) How much longer to a prototype?
+
+My gut feeling on (1) is that it will perform fine, given a suitable Python
+implementation. For example, Python code that simply looked up a dictionary
+would be fast enough - so it all depends on how fast we can make our cache.
+Re (2), it should be possible to have a "stub" process (did almost nothing in
+terms of caching or crawling, but could be connected to by the shell) in a 8
+hours, and some crawling and caching in 40. Note that this is separate from
+the work included for the shell extension itself (the implementation of which
+is largely independent of the TBZRCache implementation). So given the lack of
+a deadline for any particular feature and the better long-term fit of using
+Python, the conclusion is that we should "port" TSVN for bazaar.
+
+Reuse of this code by Mercurial or other Python based VCS systems?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Incidentally, the hope is that this work can be picked up by the Mercurial
+project (or anyone else who thinks it is of use). However, we will limit
+ourselves to attempting to find a clean abstraction for the parts that talk
+to the VCS (as good design would dictate regardless) and then try and assist
+other projects in providing patches which work for both of us. In other
+words, supporting multiple VCS systems is not an explicit goal at this stage,
+but we would hope it is possible in the future.
+
+Implementation plan
+-------------------
+
+The following is a high-level set of milestones for the implementation:
+
+* Design the RPC mechanism used for icon overlays (ie, binary format used for
+ communication).
+
+* Create Python prototype of the C++ "shim": modify the existing TBZR Python
+ code so that all references to "bzrlib" are removed. Implement the client
+ side of the RPC mechanism and implement icon overlays using this RPC
+ mechanism.
+
+* Create initial implementation of RPC server in Python. This will use
+ bzrlib, but will also maintain a local cache to achieve the required
+ performance. File crawling and watching will not be implemented at this
+ stage, but caching will (although cache persistence might be skipped).
+
+* Analyze performance of prototype. Verify that technique is feasible and
+ will offer reasonable performance and user experience.
+
+* Implement file watching, crawling etc by "porting" TSVNCache code to
+ Python, as described above.
+
+* Implement C++ shim: replace the Python prototype with a light-weight C++
+ version. We will fork the current TSVN sources, including its new
+ support for sharing icon overlays (although advice on how to setup this
+ fork is needed!)
+
+* Implement property pages and context menus in C++. Expand RPC server as
+ necessary.
+
+* Create binary for alpha releases, then go round-and-round until it's baked.
+
+Alternative Implementation Strategies
+-------------------------------------
+
+Only one credible alternative strategy was identified, as discussed below. No
+languages other than Python and C++ were considered; Python as the bzr
+library and existing extensions are written in Python and otherwise only C++
+for reasons outlined in the background on shell extensions above.
+
+Implement Completely in Python
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This would keep the basic structure of the existing TBZR code, with the
+shell extension continuing to pull in Python and all libraries used by Bzr
+into various processes.
+
+Although implementation simplicity is a key benefit to this option, it was
+not chosen for various reasons, e.g. the use of Python means that there is a
+larger chance of conflicting with existing applications, or even existing
+Python implemented shell extensions. It will also increase the memory usage
+of all applications which use the shell. While this may create problems for a
+small number of users, it may create a wider perception of instability or
+resource hogging.
diff --git a/doc/developers/transports.txt b/doc/developers/transports.txt
new file mode 100644
index 0000000..62f11ff
--- /dev/null
+++ b/doc/developers/transports.txt
@@ -0,0 +1,108 @@
+####################################
+Developer guide to bzrlib transports
+####################################
+
+This guide describes the `Transport` classes that Bazaar uses for most
+local and remote file access. (Working tree files are the major
+exception (`bug 606249 <https://bugs.launchpad.net/bzr/+bug/606249>`).
+
+
+Handling symlinks
+#################
+
+A symlink creates an alias where files or directories can be accessed by a
+different name. Symlinks are useful but raise a few annoying cases for
+bzr.
+
+It's important to have tests for symlinks but these tests can't run on
+Windows, so you need eg ::
+
+ _test_needs_features = [tests.SymlinkFeature]
+
+or ::
+
+ self.requireFeature(tests.SymlinkFeature)
+
+Bazaar versions symlinks as objects in their own right, whose content is
+the path they point to. bzr doesn't care whether a versioned
+symlink is absolute or relative; or whether it points inside or outside
+the working tree; or whether its referent exists or not. In Unix the
+target of a symlink is a byte string; bzr treats this as a Unicode string
+in the filesystem encoding (`osutils._fs_enc`).
+
+So when we say ``bzr add symlink``, this should always add the symlink to
+its containing working tree, and never dereference the symlink.
+
+However, ``bzr add symlink/file`` shouldn't add ``file`` as a child of
+``symlink``. (Symlinks don't have files underneath them: they may point to
+a directory which contains children, but if the symlink was pointed
+somewhere else those children would be unaffected.) This could either add
+the file in its containing working tree, or fail outright.
+
+One interesting case for this is ::
+
+ bzr add ~/dev/bug123/a.c
+
+where ``~/dev`` is actually a symlink to ``/srv/dev/joe/``. In this case
+clearly the user does want us to follow the symlink to open the tree.
+
+As of bzr2.2, when we open a `WorkingTree`, we typically immediately
+compute its real path and store that as ``.basedir``, but `BzrDir` stores
+its apparent path. (This may not be the best thing.)
+
+
+Useful functions
+----------------
+
+`bzrlib.osutils.dereference_path` does the commonly useful operation of
+resolving the directory part of a path, but leaving the filename
+untouched. In other words ::
+
+ ln -s x a
+ ln -s y x/b
+ dereference_path('a/b') => 'x/b'
+
+
+Relative paths beyond symlinks
+------------------------------
+
+Another interesting case is when a control directory contains a relative
+path, perhaps from a branch to its master or from a working tree to its
+branch. If it contains ``../`` parts as it typically will, these may have
+different effects depending on whether they're looked up relative to the
+real path or the apparent path given by the user. It may be that some
+users expect different behaviours at different times.
+
+Resolving the path relative to the real directory makes it somewhat more
+consistent with what you would see by in a shell entering that directory
+and then opening the given name. It may also make things more consistent
+when there are multiple links to the same bzrdir. However it may cause
+problems when using a transport that hides symlinks.
+
+We could possibly handle this by doing less path arithmetic and asking the
+OS or server to open the path including ``..`` and other relative
+elements, but that might cause other problems. HTTP servers may do their
+own path arithmetic before passing it to the OS.
+
+
+Transports that hide symlinks
+-----------------------------
+
+On local, SFTP and bzr+ssh transports, we can directly see symlinks as
+symlinks. Over HTTP (and FTP?) they're expanded by the server and we
+cannot detect them. This can cause problems when bzr follows relative
+paths because typically we will join the paths, and we may do this
+inconsistently with how the server, which can see the symlinks, would do.
+
+
+Symlinks and ChrootTransports
+-----------------------------
+
+bzr has an internal concept of a `ChrootTransport` that locks access into
+a particular directory. Symlinks should not break out of a chroot jail
+which implies they should be expanded and checked within bzrlib.
+(At least as long as the transport lets us see the symlink; otherwise it
+may not be possible.)
+
+
+ .. vim: ft=rst sw=4
diff --git a/doc/developers/ui.txt b/doc/developers/ui.txt
new file mode 100644
index 0000000..62d6388
--- /dev/null
+++ b/doc/developers/ui.txt
@@ -0,0 +1,235 @@
+=========================
+Interacting with the user
+=========================
+
+Getting Input
+=============
+
+Processing Command Lines
+------------------------
+
+bzrlib has a standard framework for parsing command lines and calling
+processing routines associated with various commands. See builtins.py
+for numerous examples.
+
+
+Standard Parameter Types
+------------------------
+
+There are some common requirements in the library: some parameters need to be
+unicode safe, some need byte strings, and so on. At the moment we have
+only codified one specific pattern: Parameters that need to be unicode
+should be checked via ``bzrlib.osutils.safe_unicode``. This will coerce the
+input into unicode in a consistent fashion, allowing trivial strings to be
+used for programmer convenience, but not performing unpredictably in the
+presence of different locales.
+
+Confirmation
+============
+
+There are some operations, such as uncommitting, or breaking a lock, where
+bzr may want to get confirmation from the user before proceeding.
+However in some circumstances bzr should just go ahead without asking: if
+it's being used from a noninteractive program, or if the user's asked to
+never be asked for this particular confirmation or for any confirmations
+at all.
+
+We provide a special UIFactory method `confirm_action` to do this. It
+takes a `confirmation_id` parameter that acts as a symbolic name for the
+type of confirmation, so the user can configure them off. (This is not
+implemented at present.) GUIs can have a "don't ask me again" option
+keyed by the confirmation id.
+
+Confirmation ids look like Python paths to the logical code that should
+use them. (Because code may move or the check may for implementation
+reasons be done elsewhere, they need not perfectly correspond to the place
+they're used, and they should stay stable even when the code moves.)
+
+``bzrlib.builtins.uncommit``
+ Before the ``uncommit`` command actually changes the branch.
+
+``bzrlib.lockdir.break``
+ Before breaking a lock.
+
+``bzrlib.msgeditor.unchanged``
+ Proceed even though the user made no changes to the template message.
+
+Interactive confirmations can be overridden by using a
+`ConfirmationUserInterfacePolicy` decorator as the default
+ui_factory.
+
+
+Writing Output
+==============
+
+(The strategy described here is what we want to get to, but it's not
+consistently followed in the code at the moment.)
+
+bzrlib is intended to be a generically reusable library. It shouldn't
+write messages to stdout or stderr, because some programs that use it
+might want to display that information through a GUI or some other
+mechanism.
+
+We can distinguish two types of output from the library:
+
+ 1. Structured data representing the progress or result of an
+ operation. For example, for a commit command this will be a list
+ of the modified files and the finally committed revision number
+ and id.
+
+ These should be exposed either through the return code or by calls
+ to a callback parameter.
+
+ A special case of this is progress indicators for long-lived
+ operations, where the caller should pass a ProgressBar object.
+
+ 2. Unstructured log/debug messages, mostly for the benefit of the
+ developers or users trying to debug problems. This should always
+ be sent through ``bzrlib.trace`` and Python ``logging``, so that
+ it can be redirected by the client.
+
+The distinction between the two is a bit subjective, but in general if
+there is any chance that a library would want to see something as
+structured data, we should make it so.
+
+The policy about how output is presented in the text-mode client
+should be only in the command-line tool.
+
+
+Progress and Activity Indications
+---------------------------------
+
+bzrlib has a way for code to display to the user that stuff is happening
+during a long operation. There are two particular types: *activity* which
+means that IO is happening on a Transport, and *progress* which means that
+higher-level application work is occurring. Both are drawn together by
+the `ui_factory`.
+
+Transport objects are responsible for calling `report_transport_activity`
+when they do IO.
+
+Progress uses a model/view pattern: application code acts on a
+`ProgressTask` object, which notifies the UI when it needs to be
+displayed. Progress tasks form a stack. To create a new progress task on
+top of the stack, call `bzrlib.ui.ui_factory.nested_progress_bar()`, then
+call `update()` on the returned ProgressTask. It can be updated with just
+a text description, with a numeric count, or with a numeric count and
+expected total count. If an expected total count is provided the view
+can show the progress moving along towards the expected total.
+
+The user should call `finish` on the `ProgressTask` when the logical
+operation has finished, so it can be removed from the stack.
+
+Progress tasks have a complex relationship with generators: it's a very
+good place to use them, but because python2.4 does not allow ``finally``
+blocks in generators it's hard to clean them up properly. In this case
+it's probably better to have the code calling the generator allocate a
+progress task for its use and then call `finalize` when it's done, which
+will close it if it was not already closed. The generator should also
+finish the progress task when it exits, because it may otherwise be a long
+time until the finally block runs.
+
+
+Message guidelines
+------------------
+
+When filenames or similar variables are presented inline within a message,
+they should be enclosed in double quotes (ascii 0x22, not chiral unicode
+quotes)::
+
+ bzr: ERROR: No such file "asdf"
+
+When we print just a list of filenames there should not be any quoting:
+see `bug 544297`_.
+
+.. _bug 544297: https://bugs.launchpad.net/bugs/544297
+
+https://wiki.ubuntu.com/UnitsPolicy provides a good explanation about
+which unit should be used when. Roughly speaking, IEC standard applies
+for base-2 units and SI standard applies for base-10 units:
+
+* for network bandwidth and disk sizes, use base-10 (Mbits/s, kB/s, GB)
+
+* for RAM sizes, use base-2 (GiB, TiB)
+
+
+
+Displaying help
+===============
+
+Bazaar has online help for various topics through ``bzr help COMMAND`` or
+equivalently ``bzr command -h``. We also have help on command options,
+and on other help topics. (See ``help_topics.py``.)
+
+As for python docstrings, the first paragraph should be a single-sentence
+synopsis of the command. These are user-visible and should be prefixed with
+``__doc__ =`` so help works under ``python -OO`` with docstrings stripped.
+
+The help for options should be one or more proper sentences, starting with
+a capital letter and finishing with a full stop (period).
+
+All help messages and documentation should have two spaces between
+sentences.
+
+
+Handling Errors and Exceptions
+==============================
+
+Commands should return non-zero when they encounter circumstances that
+the user should really pay attention to - which includes trivial shell
+pipelines.
+
+Recommended values are:
+
+ 0. OK.
+ 1. Conflicts in merge-like operations, or changes are present in
+ diff-like operations.
+ 2. Unrepresentable diff changes (i.e. binary files that we cannot show
+ a diff of).
+ 3. An error or exception has occurred.
+ 4. An internal error occurred (one that shows a traceback.)
+
+Errors are handled through Python exceptions. Exceptions should be defined
+inside bzrlib.errors, so that we can see the whole tree at a glance.
+
+We broadly classify errors as either being either internal or not,
+depending on whether ``internal_error`` is set or not. If we think it's our
+fault, we show a backtrace, an invitation to report the bug, and possibly
+other details. This is the default for errors that aren't specifically
+recognized as being caused by a user error. Otherwise we show a briefer
+message, unless -Derror was given.
+
+Many errors originate as "environmental errors" which are raised by Python
+or builtin libraries -- for example IOError. These are treated as being
+our fault, unless they're caught in a particular tight scope where we know
+that they indicate a user errors. For example if the repository format
+is not found, the user probably gave the wrong path or URL. But if one of
+the files inside the repository is not found, then it's our fault --
+either there's a bug in bzr, or something complicated has gone wrong in
+the environment that means one internal file was deleted.
+
+Many errors are defined in ``bzrlib/errors.py`` but it's OK for new errors
+to be added near the place where they are used.
+
+Exceptions are formatted for the user by conversion to a string
+(eventually calling their ``__str__`` method.) As a convenience the
+``._fmt`` member can be used as a template which will be mapped to the
+error's instance dict.
+
+New exception classes should be defined when callers might want to catch
+that exception specifically, or when it needs a substantially different
+format string.
+
+#. If it is something that a caller can recover from, a custom exception
+ is reasonable.
+
+#. If it is a data consistency issue, using a builtin like
+ ``ValueError``/``TypeError`` is reasonable.
+
+#. If it is a programmer error (using an api incorrectly)
+ ``AssertionError`` is reasonable.
+
+#. Otherwise, use ``BzrError`` or ``InternalBzrError``.
+
+Exception strings should start with a capital letter and should not have a
+final fullstop. If long, they may contain newlines to break the text.
diff --git a/doc/developers/uncommit.txt b/doc/developers/uncommit.txt
new file mode 100644
index 0000000..6d6bc9d
--- /dev/null
+++ b/doc/developers/uncommit.txt
@@ -0,0 +1,21 @@
+Uncommit Performance Notes
+==========================
+
+Specification of uncommit
+-------------------------
+
+``uncommit`` removes revisions from the head of a branch. (By default, only
+the very latest revision is removed, but optionally more can be taken.)
+Uncommit does not affect the repository (garbage collection is a separate
+step and not done by default). The working tree is not logically
+modified (revert is a different operation), except as described below
+about merges.
+
+Uncommit can be performed on either a branch or a working tree (and
+implicitly its branch.)
+
+If the uncommitted revisions includes one or more merges, after the
+uncommit those revisions are in the working tree's list of pending merges,
+because their tree changes are still present in the tree.
+
+For a bound branch, uncommit fails unless the local branch is up to date.
diff --git a/doc/developers/update.txt b/doc/developers/update.txt
new file mode 100644
index 0000000..1be814e
--- /dev/null
+++ b/doc/developers/update.txt
@@ -0,0 +1,69 @@
+"bzr update" performance analysis
+=================================
+
+There are 5 different slightly different situations in which bzr update
+can be used:
+
+* local only (no-op)
+* lightweight checkout
+* heavy checkout
+* heavy checkout w/ local changes
+* bzr update could work on "bound branch" w/no wt
+
+No new revisions
+================
+Should be O(1) to determine
+Tree base is up to date
+wt.last-rev == wt.b.last-rev
+
+No local changes, only new revisions
+====================================
+1) Need to move wt.last_rev (O(1))
+2) apply delta from base to new rev (O(changes))
+ applying changes to files is approx (O(lines-in-files ^ 2))
+3) update meta-info (executable bits, etc) about modified files (O(changes))
+
+2/3 could be concurrent (but that may not necessarily be faster)
+
+potential issue w/ serialized is having 50k files in limbo/
+
+the limbo/ directory could be avoided in some cases, for example when
+adding new files in new directories.
+
+modifying in place: reduces fragmentation of fs, not atomic
+w/ local modification, potential of data loss
+w/o should be safe
+
+"local mod" is diff between disk and last commit, not merge base
+
+Detecting name conflicts should be O(siblings). Alternatively, conflicts
+with existing files can be detected using stat() and conflicts with new files
+can be detected by examining the pending transform. This changes
+complexity to O(changes).
+
+out of date heavyweight checkout, out of date w/master
+=======================================================
+1) open working tree, check latest revision
+2) open working tree branch, check latest revision
+3) mismatch => update wt => wt.b.lastrev
+ apply delta to tree O(changed file size)
+ ---- conflicts
+ stop on conflicts
+ stop always -> inform user they need to repeat (why not?, GFD)
+4) pull new revs M => L O(newrevs)
+5) apply delta to wt
+ local committed changes become a pending merge
+ local uncommitted stay uncommitted
+ local pending merges are retained (should be gc'd)
+
+offtopic:
+should bzr update report where the source is ?
+should bzr update handle both cases (local tree out-of-date w/local branch, checkout out-of-date w/master) ?
+
+if updating would diverge, give opportuniuty to branch/unbind instead
+local ahead, "push to master"
+
+ideas:
+1) can this be done as a single logical step?
+2) can this be done w/o modifying working tree until end? possible performance improvements
+3) if the pulling revision step could deliver full texts, that may help for the merge (same thing as "bzr pull")
diff --git a/doc/developers/win32_build_setup.txt b/doc/developers/win32_build_setup.txt
new file mode 100644
index 0000000..2a06fc7
--- /dev/null
+++ b/doc/developers/win32_build_setup.txt
@@ -0,0 +1,215 @@
+===============================
+Setting Up A Windows Build Host
+===============================
+
+This document describes the steps taken to set up a Windows build host. It is
+intended to be step-by-step instructions of what packages need to be installed,
+where they can be gotten from, and how they are configured.
+
+
+Baseline
+========
+
+This was written as a step-by-step as I set up the Amazon EC2 'desolation'
+instance. This was based on an Amazon Windows 2003 instance. Also note that for
+Amazon EC2, all programs were installed into the "C:" drive, as the "D:" drive
+is essentially ``/tmp`` and is not preserved between launched instances.
+
+
+Install Packages
+================
+
+1) Download cygwin's setup.exe from http://www.cygwin.com
+ At present the current version is 1.5.25-15. This is used primarily to
+ install the build scripts and gcc-mingw. Note that we explicitly *don't*
+ install cygwin's python or bzr package. As we are only interested in
+ running the native version of bzr. For information on running the cygwin
+ port of bzr, look elsewhere.
+
+ Probably not all of these packages are necessary, but they make life easier.
+
+ a) gcc-mingw32
+ b) make
+ c) openssh
+ d) rsync
+ e) vim
+ f) wget
+ g) zip
+ h) unzip
+ i) patch
+ j) gettext-devel # brings 'msgfmt'
+
+
+2) Download the supported versions of python from http://www.python.org
+
+ a) python 2.6.4
+ b) python 2.5.4 http://www.python.org/ftp/python/2.5.4/python-2.5.4.msi
+ c) python 2.4.4 (there is no Windows installer for 2.4.5 or 2.4.6)
+ http://www.python.org/ftp/python/2.4.4/python-2.4.4.msi
+
+ Note that for Amazon EC2, all of these were installed int
+
+3) Configure 'distutils' for the compiler that you will be using. For python
+ 2.4 and 2.5 we use gcc-mingw32, for 2.6 we use Visual Studio 2008.
+
+ Edit ``D:\Python25\Lib\disutils\distutils.cfg`` (you have to create the
+ file). You want to add a section like::
+
+ [build]
+ compiler = mingw32
+
+ This also requires 'fixing' the cygwin gcc installation so that distutils
+ can find it. Specifically, it knows to look for ``gcc.exe`` however, the
+ latest versions of cygwin start using "alternatives" and making ``gcc`` just
+ a symlink.
+
+ You also need to add ``C:\cygwin\bin`` and ``C:\cygwin\lib`` into your
+ environment path. This is generally done with::
+
+ Right Click My Computer / Properties / Advanced / Environment Variables
+ System Variables / Select 'PATH' / Edit
+
+4) Download important python libraries. At the moment, the official Windows
+ all-in-one installer is built using python 2.5. We will likely soon switch
+ to python 2.6.
+
+ a) http://pypi.python.org/pypi/setuptools
+
+ Installing this first should make it easier to install some of the other
+ tools. To install something using easy install, it is generally best to
+ open up a ``cmd.exe`` shell (*not* a cygwin shell) and do::
+
+ cd C:\Python25
+ python.exe Scripts\easy_install-script.py -Z -O1 PACKAGE
+
+ The '-Z' tells it to install as a regular directory. This generally works
+ better with py2exe.
+
+ b) pywin32 http://sourceforge.net/projects/pywin32/files/
+ c) easy_install paramiko
+ This will also bring in PyCrypto and compile it, so it is important to
+ have configured step (3) correctly.
+ d) easy_install Pyrex (or Cython)
+ Note, you should probably install pyrex for all versions of python. All
+ of them need to run 'setup.py bdist_wininst' and so it is good to have it
+ build automatically, rather than setting up an explicit build order based
+ on which one has pyrex.
+ e) easy_install cogapp
+ f) install py2exe (easy_install failed)
+ http://sourceforge.net/projects/py2exe/files/
+ g) easy_install docutils
+ h) Install PyQt
+ http://www.riverbankcomputing.co.uk/software/pyqt/download
+
+ Currently they only seem to offer PyQt 4.4.3 for python 2.5 and PyQt
+ 4.6.1 for python 2.6. They generally don't make it easy to install old
+ versions of PyQt.
+ i) Install pyreadline
+ https://launchpad.net/pyreadline/+download
+ j) easy_install pygments
+ k) Patch pycrypto, so that it supports older Windows installs. (see bugs
+ #248522, #272791, #497733). The direct link to the patch is:
+ http://launchpadlibrarian.net/16133025/win32_clock.patch
+ This may not end up necessary w/ pycrypto 2.1, especially if paramiko can
+ be taught to use the new functionality (avoiding the warning).
+ l) easy_install testtools
+
+5) Get Pageant, not strictly necessary, but it is a pretty good ssh-agent for
+ Windows, and paramiko knows how to use keys from Pageant.
+
+ http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
+
+ Note that you probably want to set the environment variable
+ ``BZR_SSH=paramiko`` at this time. Otherwise it will try to use the
+ ``ssh.exe`` that it finds on your PATH (as configured in step 3), and
+ cygwin's openssh does *not* know how to access Pageant.
+
+ I usually get the 'all-in-one' installer, but only because it is easier. You
+ only really need ``pageant.exe`` and possibly ``puttygen.exe``.
+
+ If you do this, you'll probably also want to install a shortcut to
+ ``pageant.exe`` in Start / Programs / Startup so that it always starts when
+ you log in (though you still have to manually add your SSH keys.)
+
+ Note that on the Amazon EC2 machine, I'm having problems with temp files
+ being created without the permission for the current user to actually read
+ them. They seem to be owned by ``Administrator`` rather than by
+ ``Administrators``.
+
+6) Install bzr. Usually it is easiest to just get the latest all-in-one
+ installer from https://launchpad.net/bzr/+download
+
+7) Install INNOSetup from:
+ http://www.jrsoftware.org/isdl.php
+
+ After installing, you'll want to add ``C:\Program Files\Inno Setup 5`` to
+ your PATH.
+
+8) Fix distutils for the specific version of gcc. Distutils in python2.4.4 has
+ a bug where it assumes version strings have only 3 digits. The fix is to
+ just change one '?' in the regex into a '*'::
+
+ --- version.py 2009-11-05 14:41:47.497212900 -0800
+ +++ version.py 2009-11-05 14:39:57.684712900 -0800
+ @@ -97,7 +97,7 @@
+ in the distutils documentation.
+ """
+
+ - version_re = re.compile(r'^(\d+) \. (\d+) (\. (\d+))? ([ab](\d+))?$',
+ + version_re = re.compile(r'^(\d+) \. (\d+) (\. (\d+))* ([ab](\d+))?$',
+ re.VERBOSE)
+
+
+9) If you want to build in the source tree, you need the zlib dll and
+ associated libraries, put somewhere on your path. The buildout routines grab
+ this directly and add it to the build path, but that doesn't work for
+ ``setup.py``.
+ http://www.zlib.net/zlib123-dll.zip
+
+ I usually download and extract this to something like ``C:\local\`` so that
+ I end up with a ``C:\local\lib`` and ``C:\local\include`` directory. I then
+ modify the ``distutils.cfg`` file to tell the compiler where to find these
+ headers and libraries::
+
+ [build_ext]
+ include-dirs = C:/local/include
+ library-dirs = C:/local/lib
+
+ Note that you'll probably want to put the ``zlib1.dll`` into your path. You
+ can:
+
+ 1) Add ``C:\local`` to your PATH variable in
+ "My Computer/Properties/Advanced/Environment Variables"
+ 2) More logically, move ``zlib1.dll`` to either 'lib' or 'bin'
+ subdirectories and add that.
+ 3) Copy it to ``C:\Windows\``.
+
+ I recommend 3, mostly because lots of apps will want to use zlib1.dll in the
+ long run. (You may already have it.)
+
+10) Install Visual Studio 2008 Professional
+ http://www.microsoft.com/downloads/details.aspx?FamilyId=83C3A1EC-ED72-4A79-8961-25635DB0192B&displaylang=en
+
+ This is a 3GB DVD iso image. You can mount it directly with Microsofts
+ iso mounting utility:
+ http://download.microsoft.com/download/7/b/6/7b6abd84-7841-4978-96f5-bd58df02efa2/winxpvirtualcdcontrolpanel_21.exe
+
+ You need at least Windows XP (which introduced direct iso support, I
+ believe.)
+
+ Note that there is a Service Pack 1 for Visual Studio. The ISO can be
+ downloaded here:
+ http://www.microsoft.com/downloads/thankyou.aspx?familyId=27673c47-b3b5-4c67-bd99-84e525b5ce61&displayLang=en
+
+ However, on EC2, there isn't enough room on C: to actually run the
+ installer. You need approx 6GB of free disk space. And EC2 only gives your
+ 10GB and Windows itself takes up about 5GB. So we are currently running
+ stock VS 2008 with no service packs. (Even installing VS 2008 to a
+ different drive doesn't leave enough room on C: to run the upgrader.)
+
+ When installing on EC2, it seems their 2003 Server comes with a Visual
+ Studio key already supplied. There is also the possibility of using Visual
+ Studio Express Edition, but it is currently unable to compile TortoiseBzr.
+
+..
+ vim: ft=rst tw=79 et
diff --git a/doc/developers/xdg_config_spec.txt b/doc/developers/xdg_config_spec.txt
new file mode 100644
index 0000000..06135a7
--- /dev/null
+++ b/doc/developers/xdg_config_spec.txt
@@ -0,0 +1,27 @@
+Transitioning Unix installs to the XDG Base Directory Specification
+===================================================================
+
+Currently, Bazaar stores its configuration files and plugins under the
+directory ~/.bazaar on unix installs. On Windows, this is
+%APPDATA%/Bazaar/2.0 and on Mac OS X, the directory is ~/.bazaar. With the
+XDG Base Directory specification
+(http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html), many
+Linux and Unix platforms have tried to centralize configuration files under a
+specific directory referred to as $XDG_CONFIG_HOME. This has a default value
+of ~/.config.
+
+Bazaar would like to be a good Unix citizen by using these standard locations
+for configuration files. As such, we should support that location, but not
+require it. Note that the following descriptions do not apply
+to Windows or Mac OS X which should use their own native configuration
+locations. (On Windows, we currently do this by working under %APPDATA%. The
+Mac OS X equivalent would be ~/Library/Application Support/Bazaar but there is
+also cultural support for ~/.bazaar on that platform.)
+
+* If $XDG_CONFIG_HOME/bazaar exists, use the files there for configuration,
+ noting in the log that we are doing so. This allows individuals who would
+ like to use the XDG specification to do so.
+* Due to a lack of consensus on where plugins should live under the XDG Base
+ Directory spec, continue to look for plugins in ~/.bazaar/plugins. To
+ change this directory to something not under ~/.bazaar, use the environment
+ variable $BZR_PLUGIN_PATH.
diff --git a/doc/en/Makefile b/doc/en/Makefile
new file mode 100644
index 0000000..001b6d2
--- /dev/null
+++ b/doc/en/Makefile
@@ -0,0 +1,121 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS =
+SPHINXBUILD = sphinx-build
+PAPER =
+
+# Internal variables.
+PAPEROPT_a4 = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS = -d _build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+# Note that this assumes name of the output dir is same as name of the rule.
+define make_output_dirs
+# Create output directory (only needed for sphinx < 0.5)
+[ -d _build ] || mkdir _build
+[ -d "_build/$@" ] || mkdir "_build/$@"
+# Workaround for a bug in sphinx < 0.5 where it tries to delete
+# nonexistent static dirs and does not catch the exception. This was
+# fixed in svn+ssh://pythondev@svn.python.org/doctools/branches/0.4.x
+# at r65551 and merged as 280b62246342 in hg branch released as 0.5.
+[ -d "_build/$@/_static" ] || mkdir "_build/$@/_static"
+for fn in _static/*; do \
+ [ ! -d "$$fn" ] && continue; \
+ [ -d "_build/$@/$$fn" ] || mkdir "_build/$@/$$fn"; \
+done
+endef
+
+.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
+
+help:
+ @echo "Please use \`make <target>' where <target> is one of"
+ @echo " html to make standalone HTML files"
+ @echo " dirhtml to make HTML files named index.html in directories"
+ @echo " pickle to make pickle files"
+ @echo " json to make JSON files"
+ @echo " htmlhelp to make HTML files and a HTML help project"
+ @echo " qthelp to make HTML files and a qthelp project"
+ @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+ @echo " changes to make an overview of all changed/added/deprecated items"
+ @echo " linkcheck to check all external links for integrity"
+ @echo " doctest to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+ -rm -rf _build/*
+
+html:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) _build/html
+ @echo
+ @echo "Build finished. The HTML pages are in _build/html."
+
+dirhtml:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) _build/dirhtml
+ @echo
+ @echo "Build finished. The HTML pages are in _build/dirhtml."
+
+pickle:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) _build/pickle
+ @echo
+ @echo "Build finished; now you can process the pickle files."
+
+json:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) _build/json
+ @echo
+ @echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) _build/htmlhelp
+ @echo
+ @echo "Build finished; now you can run HTML Help Workshop with the" \
+ ".hhp project file in _build/htmlhelp."
+
+qthelp:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) _build/qthelp
+ @echo
+ @echo "Build finished; now you can run "qcollectiongenerator" with the" \
+ ".qhcp project file in _build/qthelp, like this:"
+ @echo "# qcollectiongenerator _build/qthelp/Bazaar.qhcp"
+ @echo "To view the help file:"
+ @echo "# assistant -collectionFile _build/qthelp/Bazaar.qhc"
+
+latex:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) _build/latex
+ @echo
+ @echo "Build finished; the LaTeX files are in _build/latex."
+ @echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+ "run these through (pdf)latex."
+
+changes:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) _build/changes
+ @echo
+ @echo "The overview file is in _build/changes."
+
+linkcheck:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) _build/linkcheck
+ @echo
+ @echo "Link check complete; look for any errors in the above output " \
+ "or in _build/linkcheck/output.txt."
+
+doctest:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) _build/doctest
+ @echo "Testing of doctests in the sources finished, look at the " \
+ "results in _build/doctest/output.txt."
+
+texinfo:
+ $(make_output_dirs)
+ $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) _build/texinfo
+ # Now build the info files using the Makefile provided by Sphinx
+ $(MAKE) -C _build/texinfo
+
diff --git a/doc/en/_static/bzr icon 16.png b/doc/en/_static/bzr icon 16.png
new file mode 100644
index 0000000..0c8d454
--- /dev/null
+++ b/doc/en/_static/bzr icon 16.png
Binary files differ
diff --git a/doc/en/_static/bzr.ico b/doc/en/_static/bzr.ico
new file mode 100644
index 0000000..a49eb7e
--- /dev/null
+++ b/doc/en/_static/bzr.ico
Binary files differ
diff --git a/doc/en/_static/en/Makefile b/doc/en/_static/en/Makefile
new file mode 100644
index 0000000..e663b44
--- /dev/null
+++ b/doc/en/_static/en/Makefile
@@ -0,0 +1,23 @@
+# If you feel the need to duplicate this file, you'll win the right to refactor
+# doc/*/quick-reference/Makefile and update TARGETS and OBJECTS usages in
+# doc/Makefile
+
+TARGETS=bzr-en-quick-reference.png bzr-en-quick-reference.pdf
+OBJECTS=bzr-en-quick-reference.svg Makefile
+
+all: $(TARGETS)
+
+.SUFFIXES: .svg .png .pdf
+
+.svg.pdf:
+ rsvg-convert -d 300 -p 300 -f pdf -o $@ $<
+
+.svg.png:
+ rsvg-convert -d 300 -p 300 -z 3.3346 -f png -o $@ $<
+
+bzr-en-quick-reference.png: $(OBJECTS)
+
+bzr-en-quick-reference.pdf: $(OBJECTS)
+
+clean:
+ rm -f $(TARGETS)
diff --git a/doc/en/_static/en/bzr-en-quick-reference.pdf b/doc/en/_static/en/bzr-en-quick-reference.pdf
new file mode 100644
index 0000000..f9c75ff
--- /dev/null
+++ b/doc/en/_static/en/bzr-en-quick-reference.pdf
Binary files differ
diff --git a/doc/en/_static/en/bzr-en-quick-reference.png b/doc/en/_static/en/bzr-en-quick-reference.png
new file mode 100644
index 0000000..4de019d
--- /dev/null
+++ b/doc/en/_static/en/bzr-en-quick-reference.png
Binary files differ
diff --git a/doc/en/_static/en/bzr-en-quick-reference.svg b/doc/en/_static/en/bzr-en-quick-reference.svg
new file mode 100644
index 0000000..5a03a42
--- /dev/null
+++ b/doc/en/_static/en/bzr-en-quick-reference.svg
@@ -0,0 +1,1598 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2766"
+ sodipodi:version="0.32"
+ inkscape:version="0.46"
+ version="1.0"
+ sodipodi:docbase="/home/ian/bzr/repo.packs/bzr.quick-start-tweaks/doc/en/quick-reference"
+ sodipodi:docname="quick-start-summary.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/iacobs/work/pers/bzr-quickref.png"
+ inkscape:export-xdpi="300"
+ inkscape:export-ydpi="300">
+ <defs
+ id="defs2768">
+ <linearGradient
+ id="linearGradient3382">
+ <stop
+ style="stop-color:#2753b0;stop-opacity:1;"
+ offset="0"
+ id="stop3384" />
+ <stop
+ style="stop-color:#cecece;stop-opacity:1;"
+ offset="1"
+ id="stop3386" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5465"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5473"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5603"
+ gradientUnits="userSpaceOnUse"
+ x1="150.39197"
+ y1="104.09448"
+ x2="151.10625"
+ y2="155.92776"
+ gradientTransform="translate(0,26)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5605"
+ gradientUnits="userSpaceOnUse"
+ x1="165.19594"
+ y1="104.09448"
+ x2="165.19594"
+ y2="156.84296"
+ gradientTransform="translate(0,26)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient8641"
+ x1="852.71942"
+ y1="104.09448"
+ x2="852.71942"
+ y2="153.842"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient8649"
+ x1="852.71942"
+ y1="104.09448"
+ x2="852.71942"
+ y2="153.842"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient8696"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient8704"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient13456"
+ gradientUnits="userSpaceOnUse"
+ x1="401.62418"
+ y1="104.09448"
+ x2="402.0069"
+ y2="152.69125" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient13458"
+ gradientUnits="userSpaceOnUse"
+ x1="401.62418"
+ y1="104.09448"
+ x2="402.0069"
+ y2="152.69125" />
+ <linearGradient
+ gradientTransform="matrix(1.027169,0,0,1,118.6039,77.1455)"
+ gradientUnits="userSpaceOnUse"
+ y2="0"
+ x2="372.24512"
+ y1="69.037941"
+ x1="372.24512"
+ id="linearGradient2200"
+ xlink:href="#linearGradient5444"
+ inkscape:collect="always" />
+ <linearGradient
+ id="linearGradient5444">
+ <stop
+ style="stop-color:#729fcf;stop-opacity:1;"
+ offset="0"
+ id="stop5446" />
+ <stop
+ id="stop4547"
+ offset="0.5"
+ style="stop-color:#3465a4;stop-opacity:1;" />
+ <stop
+ style="stop-color:#204ab7;stop-opacity:1;"
+ offset="1"
+ id="stop5448" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient5444"
+ id="linearGradient3338"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.027169,0,0,1,417.31189,-41.4259)"
+ x1="372.24512"
+ y1="69.037941"
+ x2="372.24512"
+ y2="0" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2645"
+ gradientUnits="userSpaceOnUse"
+ x1="625.15149"
+ y1="104.09448"
+ x2="625.15149"
+ y2="154.2104" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2647"
+ gradientUnits="userSpaceOnUse"
+ x1="625.15149"
+ y1="104.09448"
+ x2="625.15149"
+ y2="154.2104" />
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.70710678"
+ inkscape:cx="800.64614"
+ inkscape:cy="357.97261"
+ inkscape:document-units="px"
+ inkscape:current-layer="g3488"
+ width="1052.3622px"
+ height="744.09449px"
+ inkscape:showpageshadow="false"
+ showgrid="false"
+ inkscape:window-width="1280"
+ inkscape:window-height="752"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata2771">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <cc:license
+ rdf:resource="http://creativecommons.org/licenses/GPL/2.0/" />
+ <dc:title>Bazaar-NG quick reference</dc:title>
+ <dc:date>2007-07-23</dc:date>
+ <dc:creator>
+ <cc:Agent>
+ <dc:title>Sabin Iacob</dc:title>
+ </cc:Agent>
+ </dc:creator>
+ <dc:language>en</dc:language>
+ <dc:subject>
+ <rdf:Bag>
+ <rdf:li>bzr</rdf:li>
+ <rdf:li>bazaar</rdf:li>
+ <rdf:li>reference</rdf:li>
+ </rdf:Bag>
+ </dc:subject>
+ </cc:Work>
+ <cc:License
+ rdf:about="http://creativecommons.org/licenses/GPL/2.0/">
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/Reproduction" />
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/Distribution" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/Notice" />
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/ShareAlike" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/SourceCode" />
+ </cc:License>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <rect
+ style="opacity:1;fill:none;fill-opacity:0;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect2983"
+ width="1052.1749"
+ height="744"
+ x="0"
+ y="0.094482422"
+ ry="0" />
+ <g
+ id="g3762">
+ <g
+ id="g8706">
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect2190"
+ width="228.60797"
+ height="216.41451"
+ x="50.891964"
+ y="144.31995"
+ ry="8.1168776" />
+ <path
+ style="fill:url(#linearGradient5603);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient5605);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 59.296663,130.59448 C 54.644771,130.59448 50.891959,134.22213 50.891959,138.71888 L 50.891959,167.43551 C 50.891959,162.93876 54.644771,159.31111 59.296663,159.31111 L 271.12755,159.31111 C 275.77946,159.31111 279.49993,162.93876 279.49993,167.43551 L 279.49993,138.71888 C 279.49993,134.22213 275.77946,130.59448 271.12755,130.59448 L 59.296663,130.59448 z "
+ id="rect3430" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="108.32876"
+ y="150.97269"
+ id="text3164"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3166"
+ x="108.32876"
+ y="150.97269">Initialization</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-2.2095387)"
+ id="g3209">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="63.794312"
+ y="193.07361"
+ id="text2167"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="63.794312"
+ y="193.07361"
+ id="tspan2171">bzr init myproject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="179.83536"
+ id="text3168"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3170"
+ x="58.209351"
+ y="179.83536">New project</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.1449276)"
+ id="g3215">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="226.45848"
+ id="text2175"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan2177"
+ x="64.448624"
+ y="226.45848">cd myproject</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="237.53181"
+ id="tspan2179">bzr init</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="248.60515"
+ id="tspan2181">bzr add .</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="259.67848"
+ id="tspan2183" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.174194"
+ y="213.22023"
+ id="text3172"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3174"
+ x="58.174194"
+ y="213.22023">Existing project</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,5.3457864e-2)"
+ id="g3224">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="277.48495"
+ id="text2185"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan2187"
+ x="64.448624"
+ y="277.48495">bzr branch myproject newproject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="266.6666"
+ id="text3176"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3178"
+ x="58.209351"
+ y="266.6666">New branch</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,1.1181147)"
+ id="g3230">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="308.44989"
+ id="text3404"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3406"
+ x="64.448624"
+ y="308.44989">bzr checkout srcproject myproject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="297.63153"
+ id="text3408"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3410"
+ x="58.209351"
+ y="297.63153">New checkout</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,2.1828937)"
+ id="g3236">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="341.88864"
+ id="text3414"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan3424"
+ sodipodi:role="line"
+ x="64.448624"
+ y="341.88864">bzr checkout --lightweight \</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="352.96197"
+ id="tspan2780"> srcproject myproject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="328.59634"
+ id="text3418"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan3422"
+ sodipodi:role="line"
+ x="58.209351"
+ y="328.59634">New &quot;lightweight&quot; checkout</tspan></text>
+ </g>
+ </g>
+ <g
+ id="g3798">
+ <g
+ transform="translate(0,26)"
+ id="g10801">
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3658"
+ width="188.26918"
+ height="135.69968"
+ x="317.78247"
+ y="119.55301"
+ ry="9.6352606" />
+ <path
+ style="fill:url(#linearGradient13456);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient13458);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 327.43269,104.59448 C 322.09476,104.59448 317.77644,108.88155 317.77644,114.21948 L 317.77644,144.21948 C 317.77644,138.88155 322.09476,134.59448 327.43269,134.59448 L 496.43269,134.59448 C 501.77063,134.59448 506.05769,138.88155 506.05769,144.21948 L 506.05769,114.21948 C 506.05769,108.88155 501.77063,104.59448 496.43269,104.59448 L 327.43269,104.59448 z "
+ id="rect3648" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="333.44049"
+ y="124.94995"
+ id="text3563"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3565"
+ x="333.44049"
+ y="124.94995">File Manipulation</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.9729054)"
+ id="g3243">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="332.47345"
+ y="191.36041"
+ id="text3610"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="332.47345"
+ y="191.36041"
+ id="tspan3612">bzr add foo.py</tspan><tspan
+ id="tspan3618"
+ sodipodi:role="line"
+ x="332.47345"
+ y="202.43375">bzr add bar/</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="326.88849"
+ y="179.59872"
+ id="text3614"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3616"
+ x="326.88849"
+ y="179.59872">Add/&quot;version&quot; files</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-0.9323495)"
+ id="g3250">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="331.78732"
+ y="233.11641"
+ id="text3622"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="331.78732"
+ y="233.11641"
+ id="tspan3624">bzr remove --keep foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="326.20236"
+ y="221.35472"
+ id="text3626"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3628"
+ x="326.20236"
+ y="221.35472">Remove/&quot;unversion&quot; files</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,0.1322158)"
+ id="g3256">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="331.81714"
+ y="264.08142"
+ id="text3632"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="331.81714"
+ y="264.08142"
+ id="tspan3634">bzr remove --force foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="326.23218"
+ y="253.26308"
+ id="text3636"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3638"
+ x="326.23218"
+ y="253.26308">Remove and delete files</tspan></text>
+ </g>
+ </g>
+ <g
+ id="g3524">
+ <g
+ id="g8747">
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3780"
+ width="229.94412"
+ height="319.25848"
+ x="49.444439"
+ y="394.427"
+ ry="9.9539938" />
+ <path
+ style="fill:url(#linearGradient5465);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient5473);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 57.795026,380.59448 C 53.111409,380.59448 49.333004,384.22215 49.333004,388.71892 L 49.333004,417.43572 C 49.333004,412.93894 53.111409,409.31127 57.795026,409.31127 L 271.07052,409.31127 C 275.75416,409.31127 279.5,412.93894 279.5,417.43572 L 279.5,388.71892 C 279.5,384.22215 275.75416,380.59448 271.07052,380.59448 L 57.795026,380.59448 z "
+ id="path3784" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="111.15869"
+ y="400.96985"
+ id="text3786"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3788"
+ x="111.15869"
+ y="400.96985">Information</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,0.4441055)"
+ id="g3281">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.69976"
+ y="441.34354"
+ id="text3234"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="62.69976"
+ y="441.34354"
+ id="tspan3236">bzr status</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="57.114799"
+ y="428.10529"
+ id="text3238"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3240"
+ x="57.114799"
+ y="428.10529">Working tree status</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,1.4958392)"
+ id="g3287">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.721241"
+ y="472.84393"
+ id="text3244"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="62.721241"
+ y="472.84393"
+ id="tspan3250">bzr log</tspan><tspan
+ id="tspan3294"
+ sodipodi:role="line"
+ x="62.721241"
+ y="483.91727">bzr log foo.py</tspan><tspan
+ sodipodi:role="line"
+ x="62.721241"
+ y="494.9906"
+ id="tspan3252" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.446827"
+ y="459.55164"
+ id="text3254"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3256"
+ x="56.446827"
+ y="459.55164">Revision log</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,2.6343158)"
+ id="g3295">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="63.354061"
+ y="517.29712"
+ id="text3260"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3262"
+ x="63.354061"
+ y="517.29712">bzr diff</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="57.114803"
+ y="504.05884"
+ id="text3264"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3266"
+ x="57.114803"
+ y="504.05884">Working tree changes</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,5.8149666)"
+ id="g3314">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.744678"
+ y="625.09357"
+ id="text3298"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3300"
+ x="62.744678"
+ y="625.09357">bzr missing</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.505421"
+ y="611.85535"
+ id="text3302"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3304"
+ x="56.505421"
+ y="611.85535">Missing revisions</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,7.9315687)"
+ id="g3326">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.756401"
+ y="687.57349"
+ id="text3308"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3310"
+ x="62.756401"
+ y="687.57349">bzr cat -r3 foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.517143"
+ y="674.33521"
+ id="text3312"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan3326"
+ sodipodi:role="line"
+ x="56.517143"
+ y="674.33521">Contents of foo.py at revision 3</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,6.8799266)"
+ id="g3320">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.686089"
+ y="656.12701"
+ id="text3318"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3320"
+ x="62.686089"
+ y="656.12701">bzr info</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.446831"
+ y="645.30865"
+ id="text3322"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3324"
+ x="56.446831"
+ y="645.30865">Branch information:</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,3.685897)"
+ id="g3301">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.879452"
+ y="548.74365"
+ id="text3330"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3332"
+ x="62.879452"
+ y="548.74365">bzr diff foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.640194"
+ y="535.50537"
+ id="text3334"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3336"
+ x="56.640194"
+ y="535.50537">foo.py changes</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,4.7504623)"
+ id="g3307">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.000679"
+ y="591.70862"
+ id="text3699"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3701"
+ x="62.000679"
+ y="591.70862">bzr diff -r1..3 foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="55.761421"
+ y="568.89032"
+ id="text3703"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3705"
+ x="55.761421"
+ y="568.89032">foo.py changes between </tspan><tspan
+ id="tspan3707"
+ sodipodi:role="line"
+ x="55.761421"
+ y="580.89032">revisions 1 and 3</tspan></text>
+ </g>
+ </g>
+ <g
+ id="g3821">
+ <g
+ transform="translate(0,26)"
+ id="g10830">
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4132"
+ width="188.26918"
+ height="135.69968"
+ x="544.34027"
+ y="119.55301"
+ ry="9.6352606" />
+ <path
+ style="fill:url(#linearGradient2645);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient2647);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 553.99046,104.59448 C 548.65253,104.59448 544.33421,108.88155 544.33421,114.21948 L 544.33421,144.21948 C 544.33421,138.88155 548.65253,134.59448 553.99046,134.59448 L 722.99046,134.59448 C 728.3284,134.59448 732.61546,138.88155 732.61546,144.21948 L 732.61546,114.21948 C 732.61546,108.88155 728.3284,104.59448 722.99046,104.59448 L 553.99046,104.59448 z "
+ id="path4130" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="569.3811"
+ y="124.94995"
+ id="text4134"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4136"
+ x="569.3811"
+ y="124.94995">Version Control</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-2.4445851)"
+ id="g3262">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="559.03162"
+ y="190.88873"
+ id="text4140"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="559.03162"
+ y="190.88873"
+ id="tspan4142">bzr commit foo.py -m &quot;foo&quot;</tspan><tspan
+ id="tspan4144"
+ sodipodi:role="line"
+ x="559.03162"
+ y="201.96207">bzr commit -m &quot;the rest&quot;</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="553.44666"
+ y="180.0704"
+ id="text4146"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4148"
+ x="553.44666"
+ y="180.0704">Commit</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-2.6967609)"
+ id="g3269">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="558.37482"
+ y="232.2924"
+ id="text4152"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="558.37482"
+ y="232.2924"
+ id="tspan4154">bzr uncommit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="552.78986"
+ y="221.47408"
+ id="text4156"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4158"
+ x="552.78986"
+ y="221.47408">Undo last commit</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.6451646)"
+ id="g3275">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="558.37488"
+ y="263.73889"
+ id="text4162"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="558.37488"
+ y="263.73889"
+ id="tspan4164">bzr revert</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="552.78992"
+ y="250.50064"
+ id="text4166"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4168"
+ x="552.78992"
+ y="250.50064">Revert changes</tspan></text>
+ </g>
+ </g>
+ <g
+ id="g3844">
+ <g
+ transform="translate(0,26)"
+ id="g10882">
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4232"
+ width="228.60797"
+ height="216.41451"
+ x="770.89197"
+ y="118.31993"
+ ry="8.1168776" />
+ <path
+ style="fill:url(#linearGradient8641);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient8649);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 779.29669,104.59448 C 774.6448,104.59448 770.89199,108.22213 770.89199,112.71887 L 770.89199,141.4355 C 770.89199,136.93875 774.6448,133.3111 779.29669,133.3111 L 991.12758,133.3111 C 995.77949,133.3111 999.5,136.93875 999.5,141.4355 L 999.5,112.71887 C 999.5,108.22213 995.77949,104.59448 991.12758,104.59448 L 779.29669,104.59448 z "
+ id="path4234" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="847.87567"
+ y="124.97269"
+ id="text4236"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4238"
+ x="847.87567"
+ y="124.97269">Merging</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.0888417)"
+ id="g3392">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="783.75751"
+ y="191.95291"
+ id="text4242"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="783.75751"
+ y="191.95291"
+ id="tspan4244">cd myproject</tspan><tspan
+ sodipodi:role="line"
+ x="783.75751"
+ y="203.02624"
+ id="tspan4296">bzr merge ../myproject-foo</tspan><tspan
+ sodipodi:role="line"
+ x="783.75751"
+ y="214.09958"
+ id="tspan4298">bzr commit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17255"
+ y="178.71466"
+ id="text4246"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4248"
+ x="778.17255"
+ y="178.71466">Merge two branches</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,0.1095133)"
+ id="g3384">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.44696"
+ y="245.39931"
+ id="text4252"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4254"
+ x="784.44696"
+ y="245.39931">cd myproject-foo</tspan><tspan
+ sodipodi:role="line"
+ x="784.44696"
+ y="256.47264"
+ id="tspan4258">bzr pull ../myproject</tspan><tspan
+ sodipodi:role="line"
+ x="784.44696"
+ y="267.54597"
+ id="tspan4260" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17255"
+ y="232.16106"
+ id="text4262"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4264"
+ x="778.17255"
+ y="232.16106">Pull changes from myproject</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,1.2474884)"
+ id="g3378">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.4118"
+ y="289.69043"
+ id="text4268"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4270"
+ x="784.4118"
+ y="289.69043">bzr update</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17255"
+ y="276.5459"
+ id="text4272"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4274"
+ x="778.17255"
+ y="276.5459">Update a checkout</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,2.3122978)"
+ id="g3372">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="785.45477"
+ y="320.70923"
+ id="text4278"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4280"
+ x="785.45477"
+ y="320.70923">bzr resolve</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="779.21552"
+ y="309.83685"
+ id="text4282"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4284"
+ x="779.21552"
+ y="309.83685">Auto-detect resolved conflicts</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,3.3643062)"
+ id="g3366">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.65204"
+ y="352.20935"
+ id="text4288"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan4290"
+ sodipodi:role="line"
+ x="784.65204"
+ y="352.20935">bzr resolve foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.41278"
+ y="338.91705"
+ id="text4292"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan4294"
+ sodipodi:role="line"
+ x="778.41278"
+ y="338.91705">Specify resolved conflict</tspan></text>
+ </g>
+ </g>
+ <g
+ id="g3488">
+ <g
+ transform="translate(0,16.01004)"
+ id="g10924">
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4531"
+ width="229.94412"
+ height="319.25848"
+ x="771.12964"
+ y="378.41696"
+ ry="9.9539938" />
+ <path
+ style="fill:url(#linearGradient8704);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient8696);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 779.48025,364.58444 C 774.79663,364.58444 771.01822,368.21211 771.01822,372.70888 L 771.01822,401.42568 C 771.01822,396.9289 774.79663,393.30123 779.48025,393.30123 L 992.75574,393.30123 C 997.43938,393.30123 1001.1852,396.9289 1001.1852,401.42568 L 1001.1852,372.70888 C 1001.1852,368.21211 997.43938,364.58444 992.75574,364.58444 L 779.48025,364.58444 z "
+ id="path4533" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="838.59387"
+ y="384.95981"
+ id="text4535"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4537"
+ x="838.59387"
+ y="384.95981">Publishing</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.7634544)"
+ id="g3354">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="781.75745"
+ y="475.58072"
+ id="text4616"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="781.75745"
+ y="475.58072"
+ id="tspan4618">bzr push sftp://host/myproject-fo1</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.17249"
+ y="462.34244"
+ id="text4620"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4622"
+ x="776.17249"
+ y="462.34244">Push revisions remotely</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.1779953)"
+ id="g3360">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="782.38519"
+ y="440.54575"
+ id="text4457"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="782.38519"
+ y="440.54575"
+ id="tspan4459">bzr push ../myproject-fo1</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.80023"
+ y="429.72739"
+ id="text4461"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4463"
+ x="776.80023"
+ y="429.72739">Push revisions</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,0.3362061)"
+ id="g3346">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="782.40674"
+ y="505.56467"
+ id="text4467"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan8805"
+ sodipodi:role="line"
+ x="782.40674"
+ y="505.56467">bzr send</tspan><tspan
+ sodipodi:role="line"
+ x="782.40674"
+ y="516.638"
+ id="tspan4473" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.13232"
+ y="494.69229"
+ id="text4475"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan4608"
+ sodipodi:role="line"
+ x="776.13232"
+ y="494.69229">Email a merge directive</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,31.004958)"
+ id="g3339">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="783.03955"
+ y="562.4187"
+ id="text4481"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4483"
+ x="783.03955"
+ y="562.4187">bzr export ../myproject-dist/</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.80029"
+ y="537.18048"
+ id="text4485"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4487"
+ x="776.80029"
+ y="537.18048">Export current revision as a </tspan><tspan
+ id="tspan4610"
+ sodipodi:role="line"
+ x="776.80029"
+ y="549.18048">directory</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,33.600285)"
+ id="g3332">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="782.565"
+ y="605.85291"
+ id="text4521"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4523"
+ x="782.565"
+ y="605.85291">bzr export ../myproject-dist.zip</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.32574"
+ y="583.03461"
+ id="text4525"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4527"
+ x="776.32574"
+ y="583.03461">Export current revision as an</tspan><tspan
+ id="tspan4612"
+ sodipodi:role="line"
+ x="776.32574"
+ y="595.03461">archive</tspan></text>
+ </g>
+ <g
+ transform="translate(-1.4135726,38.47762)"
+ id="g2446">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="782.40674"
+ y="505.56467"
+ id="text2448"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan2450"
+ sodipodi:role="line"
+ x="782.40674"
+ y="505.56467">bzr send -o ../base.patch</tspan><tspan
+ sodipodi:role="line"
+ x="782.40674"
+ y="516.638"
+ id="tspan2452" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.13232"
+ y="494.69229"
+ id="text2454"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan2456"
+ sodipodi:role="line"
+ x="776.13232"
+ y="494.69229">Create a merge directive</tspan></text>
+ </g>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="144.32812"
+ y="64.254639"
+ id="text2774"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan2776"
+ x="144.32812"
+ y="64.254639">Bazaar </tspan></text>
+ <g
+ style="display:inline"
+ id="g3653"
+ transform="matrix(0.6461515,0,0,0.6526216,160.93614,144.01237)"
+ inkscape:export-filename="/home/matt/Projects/Ubuntu/Bazaar Website/bzr icon 64.png"
+ inkscape:export-xdpi="45.012665"
+ inkscape:export-ydpi="45.012665">
+ <path
+ id="path2749"
+ d="M -143.51431,-75.4275 C -158.48768,-90.57687 -171.17625,-103.66019 -171.7111,-104.50153 C -174.63909,-109.10738 -172.34363,-112.16647 -143.7155,-141.81059 C -119.96256,-166.4065 -114.08422,-171.84722 -111.26302,-171.84722 C -108.45655,-171.84722 -102.57922,-166.49332 -79.566158,-142.97326 C -59.704508,-122.67403 -51.314608,-113.24681 -51.314608,-111.22876 C -51.314608,-107.03298 -109.21126,-47.88319 -113.31814,-47.88319 C -115.49463,-47.88319 -123.57621,-55.25503 -143.51431,-75.4275 z "
+ style="opacity:1;fill:#fce94f;fill-opacity:1;stroke:#fce94f;stroke-width:4;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline" />
+ <path
+ id="path2721"
+ d="M -118.75152,-74.850683 C -119.22012,-75.319283 -119.60352,-85.958443 -119.60352,-98.493313 L -119.60352,-121.28395 L -124.85215,-121.28395 C -131.2088,-121.28395 -131.22918,-121.19503 -121.27316,-136.90004 C -116.77235,-143.99978 -113.38241,-148.09169 -112.19584,-147.85705 C -110.34853,-147.49175 -95.321883,-124.90849 -95.321883,-122.4975 C -95.321883,-121.83004 -97.640303,-121.28395 -100.47393,-121.28395 C -103.84689,-121.28395 -105.87693,-120.6299 -106.35276,-119.38989 C -107.55959,-116.24495 -103.45251,-106.32746 -97.296233,-97.520823 C -90.988133,-88.497013 -90.461803,-86.665103 -93.461883,-84.175253 C -95.128693,-82.791933 -96.185063,-83.268713 -100.25177,-87.239733 C -102.90055,-89.826193 -105.46285,-91.547323 -105.94572,-91.064423 C -106.42862,-90.581523 -106.8237,-86.544203 -106.8237,-82.092573 L -106.8237,-73.998703 L -112.36162,-73.998703 C -115.40746,-73.998703 -118.28294,-74.382103 -118.75152,-74.850683 z "
+ style="opacity:1;fill:#c4a000;fill-opacity:1;stroke:#c4a000;display:inline" />
+ <path
+ id="path2727"
+ d="M -120.75152,-76.85072 C -121.22012,-77.31932 -121.60352,-87.95848 -121.60352,-100.49335 L -121.60352,-123.28399 L -126.85215,-123.28399 C -133.2088,-123.28399 -133.22918,-123.19507 -123.27316,-138.90007 C -118.77235,-145.99981 -115.38241,-150.09172 -114.19584,-149.85708 C -112.34853,-149.49178 -97.321888,-126.90852 -97.321888,-124.49754 C -97.321888,-123.83008 -99.640308,-123.28399 -102.47393,-123.28399 C -105.84689,-123.28399 -107.87693,-122.62994 -108.35276,-121.38993 C -109.55959,-118.24499 -105.45251,-108.3275 -99.296238,-99.52086 C -92.988138,-90.49705 -92.461808,-88.66514 -95.461888,-86.17529 C -97.128698,-84.79197 -98.185068,-85.26875 -102.25177,-89.23977 C -104.90055,-91.82623 -107.46285,-93.54736 -107.94572,-93.06446 C -108.42862,-92.58156 -108.8237,-88.54424 -108.8237,-84.09261 L -108.8237,-75.99874 L -114.36162,-75.99874 C -117.40746,-75.99874 -120.28294,-76.38214 -120.75152,-76.85072 z "
+ style="opacity:1;fill:#555753;fill-opacity:1;stroke:#2e3436;stroke-opacity:1;display:inline" />
+ <path
+ d="M -143.51431,-75.4275 C -158.48768,-90.57687 -171.17625,-103.66019 -171.7111,-104.50153 C -174.63909,-109.10738 -172.34363,-112.16647 -143.7155,-141.81059 C -119.96256,-166.4065 -114.08422,-171.84722 -111.26302,-171.84722 C -108.45655,-171.84722 -102.57922,-166.49332 -79.566162,-142.97326 C -59.704512,-122.67403 -51.314612,-113.24681 -51.314612,-111.22876 C -51.314612,-107.03298 -109.21126,-47.88319 -113.31814,-47.88319 C -115.49463,-47.88319 -123.57621,-55.25503 -143.51431,-75.4275 z M -82.734602,-78.80831 C -63.284082,-98.78654 -53.870592,-109.3496 -53.870592,-111.19708 C -53.870592,-114.35673 -108.28764,-170.68595 -111.26979,-170.61328 C -113.31427,-170.56346 -167.39892,-115.6112 -169.81635,-111.12752 C -171.82156,-107.40842 -170.53236,-105.76188 -145.24612,-79.74648 C -117.66227,-51.36719 -115.36413,-49.16116 -113.38369,-49.16116 C -112.40192,-49.16116 -98.609822,-62.50237 -82.734602,-78.80831 z "
+ style="opacity:1;fill:#555753;fill-opacity:1;stroke:#2e3436;stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline"
+ id="path2736" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="146.57143"
+ y="97.808769"
+ id="text3409"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3411"
+ x="146.57143"
+ y="97.808769">Quick Reference Card</tspan></text>
+ <g
+ id="g12314"
+ transform="translate(17.946423,1.7472534)"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ sodipodi:linespacing="100%"
+ id="text8833"
+ y="527.43823"
+ x="297.99408"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:#333333;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;font-family:Bitstream Vera Sans"
+ y="527.43823"
+ x="297.99408"
+ id="tspan8835"
+ sodipodi:role="line">Supported URL Prefixes</tspan></text>
+ <g
+ id="g12288"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="299.33002"
+ y="547.94214"
+ id="text8837"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan8841"
+ x="299.33002"
+ y="547.94214">aftp://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8843"
+ x="299.33002"
+ y="565.94214">bzr://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="583.94214"
+ id="tspan10799">bzr+ssh://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8847"
+ x="299.33002"
+ y="601.94214">file:// </tspan><tspan
+ sodipodi:role="line"
+ id="tspan8849"
+ x="299.33002"
+ y="619.94214">ftp:// </tspan><tspan
+ sodipodi:role="line"
+ id="tspan8851"
+ x="299.33002"
+ y="637.94214">http://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8853"
+ x="299.33002"
+ y="655.94214">https://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="673.94214"
+ id="tspan10797" /><tspan
+ sodipodi:role="line"
+ id="tspan8855"
+ x="299.33002"
+ y="691.94214">sftp://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8857"
+ x="299.33002"
+ y="709.94214" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;opacity:1;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="379.22845"
+ y="547.94214"
+ id="text12260"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan12262"
+ x="379.22845"
+ y="547.94214">Access using active FTP.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="565.94214"
+ id="tspan12264">Fast access using the Bazaar smart server.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="583.94214"
+ id="tspan12270">Fast access using the Bazaar smart server over SSH.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="601.94214"
+ id="tspan12286">Access using the standard filesystem (default)</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="619.94214"
+ id="tspan12272">Access using passive FTP.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="637.94214"
+ id="tspan12274">Read-only access of branches exported on the web.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="655.94214"
+ id="tspan12276">Read-only access of branches exported on the web </tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="673.94214"
+ id="tspan12278">using SSL.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="691.94214"
+ id="tspan12280">Access using SFTP (most SSH servers provide SFTP).</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="709.94214"
+ id="tspan12282" /></text>
+ </g>
+ </g>
+ <g
+ id="g13619"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ sodipodi:linespacing="100%"
+ id="text4624"
+ y="320.09448"
+ x="316.78033"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:#333333;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;font-family:Bitstream Vera Sans"
+ y="320.09448"
+ x="316.78033"
+ id="tspan4626"
+ sodipodi:role="line">Concepts</tspan></text>
+ <text
+ sodipodi:linespacing="150%"
+ id="text12146"
+ y="341.21167"
+ x="447.92319"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="341.21167"
+ x="447.92319"
+ id="tspan12148"
+ sodipodi:role="line">line of development for a project</tspan><tspan
+ id="tspan12150"
+ y="359.21167"
+ x="447.92319"
+ sodipodi:role="line">version controlled directory </tspan><tspan
+ id="tspan12152"
+ y="377.21167"
+ x="447.92319"
+ sodipodi:role="line">store for Bazaar revisions</tspan><tspan
+ id="tspan12154"
+ y="395.21167"
+ x="447.92319"
+ sodipodi:role="line">version of the source code committed to the </tspan><tspan
+ id="tspan12156"
+ y="413.21167"
+ x="447.92319"
+ sodipodi:role="line">repository</tspan><tspan
+ id="tspan12158"
+ y="431.21167"
+ x="447.92319"
+ sodipodi:role="line">named revision</tspan><tspan
+ id="tspan12160"
+ y="449.21167"
+ x="447.92319"
+ sodipodi:role="line">branches having a common ancestor</tspan><tspan
+ id="tspan12164"
+ y="467.21167"
+ x="447.92319"
+ sodipodi:role="line">the operation of applying to a branch all the </tspan><tspan
+ y="485.21167"
+ x="447.92319"
+ sodipodi:role="line"
+ id="tspan3886">changes introduced by another one</tspan></text>
+ <text
+ sodipodi:linespacing="150%"
+ id="text12400"
+ y="341.21167"
+ x="317.27643"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;opacity:1;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="341.21167"
+ x="317.27643"
+ id="tspan12402"
+ sodipodi:role="line">Branch:</tspan><tspan
+ id="tspan12404"
+ y="359.21167"
+ x="317.27643"
+ sodipodi:role="line">Working tree:</tspan><tspan
+ id="tspan12406"
+ y="377.21167"
+ x="317.27643"
+ sodipodi:role="line">Repository:</tspan><tspan
+ id="tspan12408"
+ y="395.21167"
+ x="317.27643"
+ sodipodi:role="line">Revision:</tspan><tspan
+ id="tspan12410"
+ y="413.21167"
+ x="317.27643"
+ sodipodi:role="line" /><tspan
+ id="tspan12412"
+ y="431.21167"
+ x="317.27643"
+ sodipodi:role="line">Tag:</tspan><tspan
+ id="tspan12414"
+ y="449.21167"
+ x="317.27643"
+ sodipodi:role="line">Related branches:</tspan><tspan
+ id="tspan12416"
+ y="467.21167"
+ x="317.27643"
+ sodipodi:role="line">Merge:</tspan><tspan
+ id="tspan12418"
+ y="485.21167"
+ x="317.27643"
+ sodipodi:role="line"> </tspan></text>
+ </g>
+ <g
+ id="g6327"
+ transform="translate(6.5601196,0)"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ sodipodi:linespacing="100%"
+ id="text6294"
+ y="50.289795"
+ x="775.77582"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;opacity:1;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="50.289795"
+ x="775.77582"
+ id="tspan6296"
+ sodipodi:role="line">More Information</tspan></text>
+ <g
+ id="g6320"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="787.72699"
+ y="76.095581"
+ id="text6298"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan6300"
+ x="787.72699"
+ y="76.095581">bzr help</tspan></text>
+ <a
+ id="a6316"
+ style="fill:#333333;fill-opacity:1"
+ xlink:href="http://bazaar.canonical.com">
+ <text
+ sodipodi:linespacing="100%"
+ id="text6302"
+ y="97.901367"
+ x="787.79535"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="97.901367"
+ x="787.79535"
+ id="tspan6304"
+ sodipodi:role="line">http://bazaar.canonical.com</tspan></text>
+ </a>
+ </g>
+ </g>
+ </g>
+</svg>
diff --git a/doc/en/_templates/index.html b/doc/en/_templates/index.html
new file mode 100644
index 0000000..8803d02
--- /dev/null
+++ b/doc/en/_templates/index.html
@@ -0,0 +1,71 @@
+{% extends "layout.html" %}
+
+{% set title = 'Table of Contents' %}
+{% block body %}
+
+ <h2>Core documentation</h2>
+
+ <table class="contentstable" align="center" style="margin-left: 30px"><tr>
+ <td width="50%">
+ <p class="biglink"><a class="biglink" href="{{ pathto("whats-new/whats-new-in-2.6") }}">What's New in Bazaar 2.6?</a><br/>
+ <span class="linkdescr">what's new in this release</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="{{ pathto("user-guide/index") }}">User Guide</a><br/>
+ <span class="linkdescr">how to use the command line client</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="{{ pathto("tutorials/index") }}">Tutorials</a><br/>
+ <span class="linkdescr">brief introductions</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="{{ pathto("quick-reference/index") }}">Quick Reference</a><br/>
+ <span class="linkdescr">for your wall</span>
+ </p>
+ </td><td width="50%">
+ <p class="biglink"><a class="biglink" href="{{ pathto("release-notes/index") }}">Release Notes</a><br/>
+ <span class="linkdescr">a detailed log of changes</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="{{ pathto("upgrade-guide/index") }}">Upgrade Guide</a><br/>
+ <span class="linkdescr">moving to Bazaar 2.x</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="{{ pathto("user-reference/index") }}">User Reference</a><br/>
+ <span class="linkdescr">all the gory details</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="{{ pathto("admin-guide/index") }}">System Admin Guide</a><br/>
+ <span class="linkdescr">security, backups, etc.</span>
+ </p>
+ </td></tr>
+ </table>
+
+ <h2>Related links</h2>
+
+ <table class="contentstable" align="center" style="margin-left: 30px"><tr>
+ <td width="50%">
+ <p class="biglink"><a class="biglink" href="http://doc.bazaar.canonical.com/explorer/en/guide/">Desktop Guide</a><br/>
+ <span class="linkdescr">how to use our GUI applications</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="https://answers.launchpad.net/bzr/+faqs">FAQ</a><br/>
+ <span class="linkdescr">frequently asked questions</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="http://wiki.bazaar.canonical.com/BzrGlossary/">Glossary</a><br/>
+ <span class="linkdescr">help with terminology</span>
+ </p>
+ </td>
+ <td width="50%">
+ <p class="biglink"><a class="biglink" href="../developers/">Developer Docs</a><br/>
+ <span class="linkdescr">improving and extending bzr</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="http://doc.bazaar.canonical.com/migration/en/">Migration Docs</a><br/>
+ <span class="linkdescr">for refugees of other tools</span>
+ </p>
+ <p class="biglink"><a class="biglink" href="http://doc.bazaar.canonical.com/plugins/en/">Plugins Guide</a><br/>
+ <span class="linkdescr">help on popular plugins</span>
+ </p>
+ </td></tr>
+
+ <tr><td colspan="2">
+ These documents are also available in <a href="../es/index.html">Spanish</a>,
+ <a href="../ja/index.html">Japanese</a>,
+ and <a href="../ru/index.html">Russian</a>.
+ </td></tr>
+ </table>
+
+{% endblock %}
diff --git a/doc/en/_templates/layout.html b/doc/en/_templates/layout.html
new file mode 100644
index 0000000..f25e8c9
--- /dev/null
+++ b/doc/en/_templates/layout.html
@@ -0,0 +1,8 @@
+{% extends "!layout.html" %}
+
+{% block rootrellink %}
+<li><a href="http://bazaar.canonical.com/">
+ <img src="{{ pathto("_static/bzr icon 16.png", 1) }}" /> Home</a>&nbsp;|&nbsp;</li>
+<a href="http://doc.bazaar.canonical.com/en/">Documentation</a>&nbsp;|&nbsp;</li>
+{{ super() }}
+{% endblock %}
diff --git a/doc/en/admin-guide/advanced.txt b/doc/en/admin-guide/advanced.txt
new file mode 100644
index 0000000..3760917
--- /dev/null
+++ b/doc/en/admin-guide/advanced.txt
@@ -0,0 +1,164 @@
+Advanced Topics
+===============
+
+System Monitoring
+-----------------
+
+Capacity Planning Tips
+----------------------
+
+Clustering
+----------
+
+Multi-site Setups
+-----------------
+
+The "distributed" in distributed version control system should indicate that
+Bazaar is well suited for multi-site development situations and indeed, that
+is the case. The advantage comes from the ease and transparency of managing
+merges between branches with divergent history. Note that there are many,
+many different ways to manage widely-flung development setups using Bazaar and
+its branching and merging capabilities. These can be discovered and tested
+before being implemented as policy. We will describe one such possible setup
+here.
+
+Consider ProjectX Corp's international expansion with a new branch office in
+Darwin, Australia, in addition to the company's headquarters in Austin, Texas,
+USA. One of the difficulties of a far-flung multi-site development
+environment such as this is that the network connection between Australia and
+Texas is slow and unreliable. So, each branch office would like the master
+branch to be local to them. (In situations with good network connectivity, a
+local branch bound to the remote master may be all that is needed to support
+multi-site development.)
+
+Of course, with two master branches, there is always the question of which one
+is authoritative. Given Bazaar's facility at managing multiple branches, we
+suggest that it is best not to privilege either the Texas or Australia
+branches, but to merge both of them into a separate master branch (which may
+reside at either site). For definiteness, we will locate the master branch at
+the Texas site. So, we will have three branches stored on two servers:
+trunk and texas-integration at the Texas site and australia-integration at the
+Darwin site. These branches are named in terms of the sites where the
+development takes place, but in many cases it may make more sense to name
+branches after the functional teams rather their geographical locations.
+Since we are trying illustrate the issues with multi-*site* development, we
+will persist in this naming scheme.
+
+Setup
+~~~~~
+
+Using our previous setup at the Texas site, we will simply rename the old
+trunk branch as trunk and branch a copy as texas-integration.
+
+::
+
+ $ cd /srv/bzr/projectx
+ $ mv trunk trunk # can simply rename on the filesystem
+ $ bzr branch trunk texas-integration # very fast in a shared repository
+
+In Australia, we need to set up the ``/srv/bzr/projectx`` directory and get a
+copy of the current trunk as australia-integration::
+
+ $ mkdir -p /srv/bzr
+ $ cd /srv/bzr
+ $ bzr init-repo --no-trees projectx
+ $ cd projectx
+ $ bzr branch bzr+ssh://server.example.com/srv/bzr/trunk
+ $ bzr branch trunk australia-integration
+
+Merging to master
+~~~~~~~~~~~~~~~~~
+
+Then, each office works with their local copy of the trunk. At some point,
+sooner or later depending on the pace of development in the two locations, the
+two local trunks need to be merged. (In general, sooner beats later when
+merging, since there is no penalty for multiple merges.) In this example,
+Alice at the Texas office will do the merging on her local machine using
+branches on the server::
+
+ # Get a copy of the Australia branch in Texas. After the initial branch
+ # command, use pull to keep the branch up to date. With a slow network,
+ # this is the only slow part
+ $ bzr branch bzr+ssh://autralia.example.com/srv/bzr/projectx/australia-integration \
+ bzr+ssh://server.example.com/srv/bzr/projectx/australia-integration
+
+ # Check out the master branch locally for doing the merge
+ $ cd ~/projectx
+ $ bzr checkout bzr+ssh://server.example.com/srv/bzr/projectx/trunk
+ $ cd trunk
+ $ bzr merge bzr+ssh://server.example.com/srv/bzr/projectx/texas-integration
+ # Run the test suite and resolve any conflicts
+ $ bzr commit -m "Merge Texas branch to master"
+
+ # Now, merge from Australia using the local copy of that branch
+ $ bzr merge bzr+ssh://server.example.com/srv/bzr/projectx/australia-integration
+ # Run the test suite and resolve any conflicts between the two offices
+ $ bzr commit -m "Merge Australia branch to master"
+
+Note that Bazaar does not commit even cleanly applied merges by default. This
+is because although a merge may apply cleanly, the merged state still needs to
+be checked before it is committed. (Just because there are no text conflicts
+does not mean that everything will work after a merge.) An alternative that
+can pull when possible and merge otherwise is available with
+``bzr merge --pull``.
+
+Merging back to local trunks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now the trunk branch is the most up-to-date version of the software and
+both of the local trunks need to reincorporate the changes from the master.
+If no new commits have been made to texas-integration, then that can happen using
+``bzr pull``::
+
+ $ cd ~/projectx
+ $ bzr checkout bzr+ssh://server.example.com/srv/bzr/projectx/texas-integration
+ $ cd texas-integration
+ $ bzr pull ../trunk # Use trunk from the local disk
+ # No need to commit
+
+If new changes have happened on texas-integration since the integration with
+trunk, then the above pull will produce an error suggesting to use
+merge::
+
+ $ bzr merge ../trunk
+ # Run test suite, resolve conflicts
+ $ bzr commit -m "Merging Australian changes"
+
+In Australia, they will need to update their local copy of trunk::
+
+ $ cd /srv/bzr/projectx/trunk
+ $ bzr pull # parent location is used by default
+
+Then, they need to pull or merge the changes from trunk into the local trunk.
+This should be done by a developer with a checkout of australia-integration so
+that they can run the test suite::
+
+ $ cd ~/projectx
+ $ bzr co bzr+ssh://australia.example.com/srv/bzr/projectx/australia-integration
+ $ cd australia-integration
+ $ bzr merge bzr+ssh://australia.example.com/srv/bzr/projectx/trunk
+ # Run test suite and integrate Texan changes with only recent local
+ # development
+ $ bzr commit -m "Integrate work from Texas"
+
+
+Other Considerations
+~~~~~~~~~~~~~~~~~~~~
+
+Multi-site deployments can be complicated, due to the many possible variations
+of development velocity, divisions of labor, network connectivity, resources
+for integration, etc. The preceding description is meant to be one possible
+way to do fairly symmetric multi-site development. (Neither Texas or
+Australia is privileged in this structure.) In a situation where there is one
+main site and other smaller sites, one of the local trunk branches can be
+eliminated and trunk can be used directly for development at the main
+site.
+
+It is also up to the particular situation how frequently the local trunks are
+integrated into the master trunk. Given resources specifically for
+integration, it is conceivable that a developer may be constantly responsible
+for integrating changes from the two teams. Alternatively, the two sites
+could work on well-separated, well-defined features and merge to the master
+trunk only when their respective features are complete. Given the difficulty
+of resolving conflicts in very large merges and the ease of merge handling in
+Bazaar, we suggest that merges be done more frequently, rather than less.
diff --git a/doc/en/admin-guide/backup.txt b/doc/en/admin-guide/backup.txt
new file mode 100644
index 0000000..ee44612
--- /dev/null
+++ b/doc/en/admin-guide/backup.txt
@@ -0,0 +1,204 @@
+Back-up and Restore
+===================
+
+Backing up Bazaar branches can be done in two different ways. If an existing
+filesystem-based backup scheme already exists, then it can easily be used
+where the Bazaar branches reside. Alternately, Bazaar itself can be used to
+mirror the desired branches to or from another location for backup purposes.
+
+Filesystem Backups
+------------------
+
+Bazaar transactions are atomic in the sense that the disk format is such that
+it is in a valid state at any instant in time. However, for a backup process
+that takes a finite amount of time to complete, it is possible to have
+inconsistencies between different on-disk structures when backing up a live
+branch or repository. (Bazaar itself manages this concurrency issue by only
+*reading* those structures in a well-defined order.) Tools such as LVM that
+allow instantaneous snapshots of the contents of a disk can be used to take
+filesystem backups of live Bazaar branches and repositories.
+
+For other backup methods, it is necessary to take the branch or repository
+offline while the backup is being done in order to guarantee consistency
+between the various files that comprise a Bazaar branch's history. This
+requirement can be alleviated by using Bazaar as its own backup client,
+since it follows an order for reading that is designed to manage concurrent
+access (see the next section for details). Depending on the different
+access methods that are being used for a branch, there are different ways to
+take the branch "offline". For ``bzr+ssh://`` access, it is possible to
+temporarily change the filesystem permissions to prevent write access from
+any users. For ``http://`` access, changing permissions, shutting down
+the HTTP server or switching the server to a separate configuration that
+disallows access are all possible ways to take a branch offline for backup.
+Finally, for direct filesystem access, it is necessary to make the branch
+directories un-writable.
+
+Because this sort of downtime can be very disruptive, we strongly encourage
+using Bazaar itself as a backup client, where branches are copied and
+updated using Bazaar directly.
+
+
+Bazaar as its own backup
+------------------------
+
+The features that make Bazaar a good distributed version control system also
+make it a good choice for backing itself up. In particular, complete and
+consistent copies of any branch can easily be obtained with the ``branch`` and
+``pull`` commands. As a result, a backup process can simply run ``bzr pull``
+on a copy of the main branch to fully update that copy. If this backup
+process runs periodically, then the backups will be as current as the last
+time that ``pull`` was run. (This is in addition to the fact
+that revisions are immutable in Bazaar so that a prior revision of a branch is
+always recoverable from that branch when the revision id is known.)
+
+As an example, consider a separate backup server that stores backups in
+``/var/backup``. On that server, we could initially run
+
+::
+
+ $ cd /var/backup
+ $ bzr branch bzr+ssh://server.example.com/srv/bzr/trunk
+ $ bzr branch bzr+ssh://server.example.com/srv/bzr/feature-gui
+
+to create the branches on the backup server. Then, we could regularly (for
+example from ``cron``) do
+
+::
+
+ $ cd /var/backup/trunk
+ $ bzr pull # the location to pull from is remembered
+ $ cd ../var/backup/feature-gui
+ $ bzr pull # again, the parent location is remembered
+
+The action of pulling from the parent for all branches in some directory is
+common enough that there is a plugin to do it. The `bzrtools`_ plugin
+contains a ``multi-pull`` command that does a ``pull`` in all branches under a
+specified directory.
+
+.. _bzrtools: http://launchpad.net/bzrtools
+
+With this plugin installed, the above periodically run commands would be
+
+::
+
+ $ cd /var/backup
+ $ bzr multi-pull
+
+Note that ``multi-pull`` does a pull in *every* branch in the specified
+directory (the current directory by default) and care should be taken that
+this is the desired effect. A simple script could also substitute for the
+multi-pull command while also offering greater flexibility.
+
+Bound Branch Backups
+~~~~~~~~~~~~~~~~~~~~
+
+When ``bzr pull`` is run regularly to keep a backup copy up to date, then it
+is possible that there are new revisions in the original branch that have not
+yet been pulled into the backup branch. To alleviate this problem, we can set
+the branches up so that new revisions are *pushed* to the backup rather than
+periodically pulling. One way to do this is using Bazaar's concept of bound
+branches, where a commit in one branch happens only when the same commit
+succeeds in the branch to which it is `bound`. As a push-type technology, it
+is set up on the server itself rather than on the backup machine. For each
+branch that should be backed up, you just need to use the ``bind`` command to
+set the URL for the backup branch. In our example, we first need to create
+the branches on the backup server (we'll use ``bzr push``, but we could as
+easily have used ``bzr branch`` from the backup server)
+
+::
+
+ $ cd /srv/bzr/projectx/trunk
+ $ bzr push bzr+ssh://backup.example.com/var/backup/trunk
+ $ cd ../feature-gui
+ $ bzr push bzr+ssh://backup.example.com/var/backup/feature-gui
+
+and then we need to bind the main branches to their backups
+
+::
+
+ $ cd ../trunk
+ $ bzr bind bzr+ssh://backup.example.com/var/backup/trunk
+ $ cd ../feature-gui
+ $ bzr bind bzr+ssh://backup.example.com/var/backup/feature-gui
+
+A branch can only be bound to a single location, so multiple backups cannot
+be created using this method.
+
+Using the `automirror`_ plugin mentioned under `Hooks and Plugins <hooks-plugins.html>`_, one can
+also make a push-type backup system that more naturally handles mutliple
+backups. Simply set the ``post_commit_mirror`` option to multiple URLs
+separated by commas. In order to backup to the backup server and a
+remote location, one could do
+
+::
+
+ $ cd /srv/bzr/trunk
+ $ echo "post_commit_mirror=bzr+ssh://backup.example.com/var/backup/trunk,\
+ bzr+ssh://offsite.example.org/projectx-corp/backup/trunk" >> .bzr/branch/branch.conf
+ $ cd ../feature-gui
+ $ echo "post_commit_mirror=bzr+ssh://backup.example.com/var/backup/feature-gui,\
+ bzr+ssh://offsite.example.org/projectx-corp/backup/feature-gui" >> .bzr/branch/branch.conf
+
+.. _automirror: http://launchpad.net/bzr-automirror
+
+As for any push-type backup strategy that maintains consistency, the downside
+of this method is that all of the backup commits must succeed before the
+initial commit can succeed. If there is a many mirror branches or if the bound
+branch has a slow network connection, then the delay in the original commit may
+be unacceptably long. In this case, pull-type backups, or a mixed system may
+be preferable.
+
+
+Restoring from Backups
+----------------------
+
+Checking backup consistency
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Many a system administrator has been bitten by having a backup process,
+but when it came time to restore from backups, finding out that the backups
+themselves were flawed. As such, it is important to check the quality of the
+backups periodically. In Bazaar, there are two ways to do this: using the
+``bzr check`` command and by simply making a new branch from the backup. The
+``bzr check`` command goes through all of the revisions in a branch and checks
+them for validity according to Bazaar's internal invariants. Since it goes
+through every revision, it can be quite slow for large branches. The other
+way to ensure that the backups can be restored from is to perform a test
+restoration. This means performing the restoration process in a temporary
+directory. After the restoration process, ``bzr check`` may again be relevant
+for testing the validity of the restored branches. The following two sections
+present two restoration recipes.
+
+Restoring Filesystem Backups
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are many different backup tools with different ways of accessing the
+backup data, so we can't cover them all here. What we will say is that
+restoring the contents of the ``/srv/bzr`` directory completely will restore
+all branches stored there to their state at the time of the backup (see
+`Filesystem Backups`_ for concerns on backing up live branches.) For
+example, if the backups were mounted at ``/mnt/backup/bzr`` then we could
+restore using simply::
+
+ $ cd /srv
+ $ mv bzr bzr.old
+ $ cp -r /mnt/backup/bzr bzr
+
+Of course, to restore only a single branch from backup, it is sufficient to
+copy only that branch. Until the restored backup has been successfully used
+in practice, we recommend keeping the original directory available.
+
+Restoring Bazaar-based Backups
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to restore from backup branches, we can simply branch them into the
+appropriate location::
+
+ $ cd /srv
+ $ mv bzr bzr.old
+ $ cd bzr
+ $ bzr branch bzr+ssh://backup.example.com/var/backup/trunk
+ $ bzr branch bzr+ssh://backup.example.com/var/backup/feature-gui
+
+If there are multiple backups, then change the URL above to restore from the
+other backups.
diff --git a/doc/en/admin-guide/code-browsing.txt b/doc/en/admin-guide/code-browsing.txt
new file mode 100644
index 0000000..d1bf238
--- /dev/null
+++ b/doc/en/admin-guide/code-browsing.txt
@@ -0,0 +1,128 @@
+Web-based code browsing
+=======================
+
+Browsing the history of a project online is an important part of version
+control, since it allows people to easily see what happens in a branch
+without having to have a local, up-to-date copy of that branch. There are a
+number of possible choices for browsing Bazaar branches on the web, but we
+will cover one of them in particular detail and briefly mention the other
+choices where they differ.
+
+Loggerhead
+----------
+
+Loggerhead_ is a code browsing interface for Bazaar branches (now used in
+Launchpad). To see an example of Loggerhead in action, browse to
+http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/files which is the loggerhead
+view of Bazaar's trunk branch. Loggerhead runs as a web application on the
+server which is accessed over HTTP via a RESTful interface. It is possible to
+run this application on its own dedicated port as
+``http://www.example.com:8080`` or to proxy this location behind a separate web
+server, for example at ``http://www.example.com/loggerhead/``. We will discuss
+both of these configurations below.
+
+.. _Loggerhead: http://launchpad.net/loggerhead
+
+Requirements
+~~~~~~~~~~~~
+
+Loggerhead depends on a number of other Python packages for the various Web
+technologies that it builds on. Some of these must be installed to use
+loggerhead, although some of them are optional. From the loggerhead `README`
+file, these are
+
+1) SimpleTAL for templating.
+ On Ubuntu, `sudo apt-get install python-simpletal`
+ or download from http://www.owlfish.com/software/simpleTAL/download.html
+2) simplejson for producing JSON data.
+ On Ubuntu, `sudo apt-get install python-simplejson`
+ or use `easy_install simplejson`.
+3) Paste for the server. (You need version 1.2 or newer of Paste.)
+ On Ubuntu, `sudo apt-get install python-paste`
+ or use `easy_install Paste`
+4) Paste Deploy (optional, needed when proxying through Apache)
+ On Ubuntu, `sudo apt-get install python-pastedeploy`
+ or use `easy_install PasteDeploy`
+5) flup (optional, needed to use FastCGI, SCGI or AJP)
+ On Ubuntu, `sudo apt-get install python-flup`
+ or use `easy_install flup`
+
+Although directions for installing these on Ubuntu are given, most other
+GNU/Linux distributions should package these dependencies, making installation
+easy. For Windows and Mac OS X, they should all be ``easy_install``-able or at
+worst installable from the Python sources.
+
+Built-in Web Server
+~~~~~~~~~~~~~~~~~~~
+
+Loggerhead has a built-in web server and when started with the
+``serve-branches`` command, that web server is started on a default port
+listening on the localhost. If port 8080 (the default) is accessible on
+``www.example.com``, then running
+
+::
+
+ $ serve-branches --host=www.example.com --port=8080 /srv/bzr
+
+will list all of the available branches under that directory on
+``http://www.example.com:8080/``, so that the ProjectX trunk could be browsed
+at ``http://www.example.com:8080/projectx/trunk``. Note that loggerhead
+provides HTTP access to the underlying Bazaar branches (similar to that
+described in `Smart server over HTTP(S)
+<other-setups.html#smart-server-over-http-s>`_), so this command should be run
+as a user without write privileges in ``/srv/bzr``. By default, loggerhead
+only listens on the localhost, not any external ports, unless specified as
+above.
+
+Behind a Proxy
+~~~~~~~~~~~~~~
+
+A more common and more safe way to run loggerhead is behind another web server
+which will proxy certain requests to the loggerhead server on the localhost.
+To do this, you need to have PasteDeploy installed (see `Requirements`_).
+Assuming that your server has Apache running, you need to add configuration
+such as this to set up the proxy
+
+::
+
+ <Location "/loggerhead/">
+ ProxyPass http://127.0.0.1:8080/
+ ProxyPassReverse http://127.0.0.1:8080/
+ </Location>
+
+If your proxy runs at some path within the server, then the ``serve-branches``
+command must be started with the ``--prefix`` option. For this example, we
+could start loggerhead with the command
+
+::
+
+ $ serve-branches --prefix=/loggerhead /srv/bzr
+
+This would allow the trunk branch of ProjectX to be browsed at
+``http://www.example.com/loggerhead/projectx/trunk``.
+
+Loggerhead comes with a script allowing it to run as a service on
+``init.d`` based Unix systems. Contributions to do a similar thing on
+Windows servers would be welcomed at http://launchpad.net/loggerhead.
+
+
+Other web interfaces
+--------------------
+
+There are a number of other web interfaces available for Bazaar branches (see
+the list at http://wiki.bazaar.canonical.com/WebInterfaces) and we will just
+mention a couple of them here for their advantages in particular situations.
+
+trac+bzr (http://launchpad.net/trac-bzr)
+ Trac is a popular web app that integrates a browser for branches, an issue
+ tracker and a wiki. trac+bzr is a trac extension that allows for the
+ trac to be used with Bazaar.
+
+webbzr (http://thoughts.enseed.com/webbzr)
+ This is a notable solution because it is written in pure PHP for web hosts
+ that don't provide a way to run arbitrary Python applications such as Trac
+ or Loggerhead.
+
+Redmine (http://redmine.org/)
+ Like trac, Redmine is a full project management application using the Ruby
+ on Rails framework. It includes support for Bazaar branches.
diff --git a/doc/en/admin-guide/hooks-plugins.txt b/doc/en/admin-guide/hooks-plugins.txt
new file mode 100644
index 0000000..11fe8bd
--- /dev/null
+++ b/doc/en/admin-guide/hooks-plugins.txt
@@ -0,0 +1,310 @@
+Extending Bazaar with Hooks and Plugins
+=======================================
+
+Bazaar offers a powerful extension mechanism for adding capabilities. In
+addition to offering full library API access to all of its structures, which
+can be useful for outside programs that would like to interact with Bazaar
+branches, Bazaar can also load *plugins* that perform specific tasks. These
+specific tasks are specified by *hooks* that run during certain steps of the
+version control process.
+
+For full documentation on the available hooks, see ``bzr help hooks``. Among
+those, some of the most significant hooks from an administration
+standpoint are `pre_commit`, `post_commit` and `post_change_branch_tip`.
+A `pre_commit` hook can inspect a commit before it happens and cancel it if
+some criteria are not met. This can be useful for enforcing policies about
+the code, such as line-endings or whitespace conventions. A
+`post_commit` hook can take actions based on the commit that just happened,
+such as providing various types of notifications. Finally, a
+`post_change_branch_tip` hook is a more general form of a `post_commit`
+hook which is used whenever the tip of a branch changes (which can happen in
+more ways than just committing). This too can be used for notification
+purposes, as well as for backups and mirroring.
+
+Information on the whole range of Bazaar plugins is available at
+http://doc.bazaar.canonical.com/plugins/en/. For purposes of installation,
+plugins are simply python packages. They can be installed alongside Bazaar in
+the ``bzrlib.plugins`` package using each plugin's ``setup.py``. They can
+also be installed in the plugin path which is the user's ``~/.bazaar/plugins``
+directory or can be specified with the ``BZR_PLUGIN_PATH`` environment
+variable. See ``bzr help configuration`` for more on specifying the location
+of plugins.
+
+
+Email Notification
+------------------
+
+A common need is for every change made on a branch to send an email message to
+some address, most often a mailing list. These plugins provide that capability
+in a number of different ways.
+
+The `email` plugin sends email from each individual developer's computer. This
+can be useful for situations that want to track what each individual developer
+is working on. On the downside, it requires that every developer's branches be
+configured individually to use the same plugin.
+
+The next two plugins `hookless-email` and `email-notifier` address this concern
+by running on a central server whenever changes happen on centrally stored
+branches.
+
+email
+~~~~~
+
+To configure this plugin, simply install the plugin and configure the
+``post_commit_to`` option for each branch. This configuration can be done
+in the ``locations.conf`` file or individually in each branch's
+``branch.conf`` file. The sender's email address can be specified as
+``post_commit_sender`` if it is different than the email address reported by
+``bzr whoami``. The ``post_commit_mailer`` option specifies how the
+mail should be sent. If it isn't set, email is sent via ``/usr/bin/mail``.
+It can also be configured to communicate directly with an SMTP server.
+For more details on configuring this plugin, see
+http://doc.bazaar.canonical.com/plugins/en/email-plugin.html. As examples,
+consider the following two possible configurations. A minimal one (uses
+``/usr/bin/mail``)
+
+::
+
+ [DEFAULT]
+ post_commit_to = projectx-commits@example.com
+
+and a more complicated one (using all of the options)
+
+::
+
+ [DEFAULT]
+ post_commit_url = http://www.example.com/code/projectx/trunk
+ post_commit_to = projectx-commits@example.com
+ post_commit_sender = donotreply@example.com
+ post_commit_mailer = smtplib
+ smtp_server = mail.example.com:587
+ smtp_username = bob
+ # smtp_password = 'not specified, will prompt'
+
+
+hookless-email
+~~~~~~~~~~~~~~
+
+This plugin is basically a server-side version of the `email` plugin. It is
+a program that runs either from the command line or as a daemon that monitors
+the branches specified on the command line for any changes. When a change
+occurs to any of the monitored branches, it will send an email to the
+specified address. Using our simple example, the following command would send
+an email to ``projectx-commits@example.com`` on any of the branches under
+``/srv/bzr`` since the last time the command was run. (This command could be
+set up to run at regular intervals, for example from ``cron``.)
+
+::
+
+ $ bzr_hookless_email.py --email=projectx-commits@example.com \
+ --recurse /srv/bzr
+
+email-notifier
+~~~~~~~~~~~~~~
+
+This is a more elaborate version of the `hookless-email` plugin that can send
+templated HTML emails, render wiki-style markup in commit messages and update
+working copies on the server (similar to `push_and_update`_). It can also
+send emails reporting the creation of new branches or the removal of branches
+under a specified directory (here ``/srv/bzr/projectx``). As it is more
+complicated, its configuration is also more complicated and we won't repeat
+its documentation here, but a simple configuration that will send emails on
+commits and creation/deletion of branches is
+
+::
+
+ [smtp]
+
+ server=smtp.example.com
+ # If user is not provided then no authentication will be performed.
+ user=bob
+ password=pAssW0rd
+
+ [commits]
+
+ # The address to send commit emails to.
+ to=projctx-commits@example.com
+ from=$revision.committer
+
+ # A Cheetah template used to construct the subject of the email message.
+ subject=$relative_path: $revision_number $summary
+
+ [new-branches]
+ to=projectx-commits@example.com
+ from=donotreply@example.com
+ subject=$relative_path: New branch created
+
+ [removed-branches]
+ to=projectx-commits@example.com
+ from=donotreply@example.com
+ subject=$relative_path: Branch removed
+
+If this file is stored as ``/srv/bzr/email-notifier.conf``, then the command
+
+::
+
+ $ bzr-email-notifier.py --config=/srv/bzr/email-notifier.conf /srv/bzr/projectx
+
+will watch all branches under the given directory for commits, branch
+creations and branch deletions.
+
+
+Feed Generation
+---------------
+
+A related concept to sending out emails when branches change is the generation
+of news feeds from changes on each branch. Interested parties can then choose
+to follow those news feeds in order to see what is happening on a branch.
+
+branchfeed
+~~~~~~~~~~
+
+This plugin creates an ATOM feed for every branch on every branch change
+(commit, etc.). It stores these files as ``.bzr/branch/branch.atom`` inside
+each branch. Currently, it includes the 20 most recent changes in each feed.
+To use it, simply install the plugin and set your feed reader to follow the
+``branch.atom`` files.
+
+In addition, there are other tools that are not plugins for creating news
+feeds from Bazaar branches. See
+http://wiki.bazaar.canonical.com/FeedGenerators for more on those tools.
+
+Mirroring
+---------
+
+Sometimes it is useful to ensure that one branch exists as an exact copy of
+another. This can be used to provide simple backup facilities or redundancy
+(see `Back-up and restore <backup.html>`_ for more details on backups). One
+way to do this using Bazaar's workflows is to make the branch where changes
+happen into a bound branch of the mirror branch. Then, when commits happen on
+the working branch, they will also happen on the mirror branch. Note that
+commits to bound branches do *not* update the mirror branch's working copy, so
+if the mirror branch is more than just a backup of the complete history of the
+branch, for example if it is being served as a web page, then additional
+plugins are necessary.
+
+push_and_update
+~~~~~~~~~~~~~~~
+
+This plugin updates Bazaar's ``push`` command to also update the remote
+working copy. It can only work over connections that imply filesystem or SSH
+access to the remote working copy (``bzr+ssh://``, ``sftp://`` and
+``file://``). Also, it is only useful when the remote branch is updated with
+an explicit ``push`` command.
+
+automirror
+~~~~~~~~~~
+
+This plugin is similar to `push_and_update` in that it updates the working
+copy of a remote branch. The difference is that this plugin is designed to
+update the remote branch on every change to the working branch. To configure
+this, set the ``post_commit_mirror = URL`` option on a branch. This option
+can include multiple branch URLs separated by commas to create multiple
+mirrors. For example, if we want to mirror our ``/srv/bzr/projectx/trunk``
+branch to the URL ``sftp://www.example.com/var/www/projectx`` (for example if
+ProjectX were a web project that we wanted to access at
+``http://www.example.com/projectx``), then we could include
+
+::
+
+ [DEFAULT]
+ post_commit_mirror = sftp://www.example.com/var/www/branches/trunk
+
+in the file ``/srv/bzr/projectx/trunk/.bzr/branch/branch.conf``.
+
+
+Other Useful Plugins
+--------------------
+
+pqm (plugin)
+~~~~~~~~~~~~
+
+Facilitating interaction with `PQM
+<integration.html#patch-queue-manager-pqm>`_, this plugin provides support for
+submitting merge requests to a remote Patch Queue Manager. PQM provides
+a way to automatically run the test suite before merging changes to the
+trunk branch.
+
+testrunner
+~~~~~~~~~~
+
+Sometimes referred to as the poor man's PQM, this plugin runs a single command
+on the updated revision (in a temporary directory) and if the command returns
+0, then the revision can be committed to that branch. For example, if the
+testsuite is run with the command ``nosetests`` in the root of the branch
+(which returns 0 if the test suite passes and 1 if it doesn't pass), then one
+can set
+
+::
+
+ [DEFAULT]
+ pre_change_branch_tip_test_command = nosetests
+
+in ``.bzr/branch/branch.conf``.
+
+checkeol
+~~~~~~~~
+
+This plugin is an example of a `pre_commit` hook that checks the revision
+being committed for meeting some policy. In this case, it checks that all of
+the files have the specified line endings. It uses a configuration file
+``.bzreol`` in the root of the working tree (similar to the ``.bzrignore``
+file). This configuration file has sections for line feed endings (LF),
+carriage return/line-feed endings (CRLF) and carriage return endings (CR).
+For an unusual example that specifies different line endings for different
+files, that file might look like
+
+::
+
+ [LF]
+ *.py
+ *.[ch]
+
+ [CRLF]
+ *.txt
+ *.ini
+
+ [CR]
+ foo.mac
+
+or if you simply want to enforce a single line ending convention on the branch
+you can use
+
+::
+
+ [LF]
+ *
+
+This plugin needs to be installed on the server where the branch updates will
+happen, and the ``.bzreol`` file must be in each branch where line ending
+policies will be enforced. (Adding it to the branch with ``bzr add .bzreol``
+is an easy way to ensure this, although it means that branches on the server
+must have working trees.)
+
+text_checker
+~~~~~~~~~~~~
+
+This plugin is a more advanced version of `checkeol` that can check such
+coding style guidelines such as trailing whitespace, long lines and files that
+don't end with a newline. It is configured using Bazaar's built in rules
+specification in ``BZR_HOME/rules`` (see ``bzr help rules`` for more
+information. For different types of undesired changes, you can specify
+different types of actions. For example
+
+::
+
+ [name NEWS README]
+ trailing_whitespace=fail
+ long_lines=warn
+ newline_at_eof=ignore
+
+ [name *.py]
+ tabs=fail
+ long_line_length=78
+ long_lines=fail
+ trailing_whitespace=fail
+
+will prevent changes from adding new trailing whitespace to the specified
+files and keep all python source files free of tabs and lines over 78
+characters. To commit while violating these rules, one can pass the
+``--text-check-warn-only`` option to commit.
diff --git a/doc/en/admin-guide/index-plain.txt b/doc/en/admin-guide/index-plain.txt
new file mode 100644
index 0000000..e62ab6e
--- /dev/null
+++ b/doc/en/admin-guide/index-plain.txt
@@ -0,0 +1,24 @@
+###################################
+Bazaar System Administrator's Guide
+###################################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+.. contents:: :depth: 3
+
+.. include:: introduction.txt
+.. include:: simple-setups.txt
+.. include:: other-setups.txt
+.. include:: migration.txt
+.. include:: hooks-plugins.txt
+.. include:: code-browsing.txt
+.. include:: integration.txt
+.. include:: security.txt
+.. include:: backup.txt
+.. include:: upgrade.txt
+.. include:: advanced.txt
+.. include:: licence.txt
diff --git a/doc/en/admin-guide/index.txt b/doc/en/admin-guide/index.txt
new file mode 100644
index 0000000..8d5326b
--- /dev/null
+++ b/doc/en/admin-guide/index.txt
@@ -0,0 +1,26 @@
+###################################
+Bazaar System Administrator's Guide
+###################################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+
+.. toctree::
+ :maxdepth: 2
+
+ introduction
+ simple-setups
+ other-setups
+ migration
+ hooks-plugins
+ code-browsing
+ integration
+ security
+ backup
+ upgrade
+ advanced
+ licence
diff --git a/doc/en/admin-guide/integration.txt b/doc/en/admin-guide/integration.txt
new file mode 100644
index 0000000..57502b3
--- /dev/null
+++ b/doc/en/admin-guide/integration.txt
@@ -0,0 +1,14 @@
+Integration with Other Tools
+============================
+
+Patch Queue Manager (PQM)
+-------------------------
+
+Bug Trackers
+------------
+
+Continuous Integration Tools
+----------------------------
+
+Bundle Buggy
+------------
diff --git a/doc/en/admin-guide/introduction.txt b/doc/en/admin-guide/introduction.txt
new file mode 100644
index 0000000..2df463c
--- /dev/null
+++ b/doc/en/admin-guide/introduction.txt
@@ -0,0 +1,55 @@
+Introduction
+============
+
+Welcome to the Bazaar Version Control System's guide for system
+administrators. Bazaar is a flexible system that provides many possible
+options for serving projects in ways that will hopefully meet your needs. If
+you have requirements that are not met by the current state of the Bazaar
+ecosystem, please let us know at bazaar@lists.canonical.com or on Launchpad at
+https://launchpad.net/bzr.
+
+Scope of this guide
+-------------------
+
+In this guide, we will discuss various techniques for making Bazaar projects
+available, migrating from other Version Control Systems, browsing code over
+the Web and combining Bazaar with other tools. In many of these categories,
+multiple options exist and we will try to explains the costs and benefits of
+the various options.
+
+The intended audience for this guide is the individuals who administer the
+computers that will do the serving. Much of the configuration that we will
+discuss requires administrator privileges and we will not necessarily indicate
+every point that those privileges are needed. That said, reading this guide
+can also be very helpful for those who are interested in communicating to the
+system administrators about the requirements for making full use of Bazaar.
+
+What you need to run a Bazaar server
+------------------------------------
+
+Where possible, we will discuss both Unix (including GNU/Linux) and Windows server
+environments. For the purposes of this document, we will consider Mac OS X as
+a type of Unix.
+
+In general, Bazaar requires only Python_ 2.4 or greater and the cElementTree_
+package (included in Python 2.5 and later) to run. If you would *optionally*
+like to be able to access branches using SFTP, you need `paramiko and
+pycrypto`_.
+
+.. _Python: http://www.python.org/
+.. _cElementTree: http://effbot.org/zone/element-index.htm
+.. _paramiko and pycrypto: http://www.lag.net/paramiko/
+
+For maximum performance, Bazaar can make use of compiled versions of some
+critical components of the code. Pure Python alternatives exist for all of
+these components, but they may be considerably slower. To compile these
+extensions, you need a C compiler and the relevant header files from the
+Python package. On GNU/Linux, these may be in a separate package. Other
+operating systems should have the required headers installed by default.
+
+If you are installing a development version of Bazaar, rather than a released
+version, you will need Pyrex_ to create the C extensions. The release
+tarballs already have the Pyrex-created C files.
+
+.. _Pyrex: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
+
diff --git a/doc/en/admin-guide/licence.txt b/doc/en/admin-guide/licence.txt
new file mode 100644
index 0000000..76a34c3
--- /dev/null
+++ b/doc/en/admin-guide/licence.txt
@@ -0,0 +1,7 @@
+Licence
+===============
+
+Copyright 2008-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
diff --git a/doc/en/admin-guide/migration.txt b/doc/en/admin-guide/migration.txt
new file mode 100644
index 0000000..b35a108
--- /dev/null
+++ b/doc/en/admin-guide/migration.txt
@@ -0,0 +1,73 @@
+Migration
+=========
+
+Migrating between version control systems can be a complicated process, and
+Bazaar has extensive documentation on the process at
+http://doc.bazaar.canonical.com/migration/en and we won't attempt to repeat that
+here. We will try to give a few motivating examples for conversion from
+Mercurial and Subversion.
+
+Fast Import
+-----------
+
+In many projects wishing to use Bazaar, there is pre-existing history for the
+codebase that should be taken into consideration. Bazaar leverages an
+interchange format originally developed for Git called `fast-import` to
+provide migration strategies for many other version control systems. To
+work with fast-import files, Bazaar needs the `fastimport`_ plugin. This can
+be installed as with any Bazaar plugin.
+
+.. _fastimport: http://launchpad.net/bzr-fastimport
+
+The way that fast-import can be used for migration is to export the existing
+history into a fast-import file, then use the ``bzr fast-import`` command.
+The `fastimport` plugin includes exporters for Subversion, CVS, Git, Mercurial
+and darcs, accessible as the ``fast-export-from-XXX`` commands. Note that
+``fast-import`` should not be used in a branch with existing history.
+
+Assuming that ProjectX was first developed in Mercurial before switching to
+Bazaar, and that the Mercurial repository is in ``/srv/hg/projectx``, the
+following commands will import that history into a newly created ``trunk``
+branch. (Recall that in `Further Configuration
+<simple-setups.html#further-configuration>`_ we created the
+``/srv/bzr/projectx`` directory as a shared repository.)
+
+::
+
+ $ cd /srv/bzr/projectx
+ $ bzr fast-export-from-hg ../../hg/projectx projectx.fi
+ $ bzr init trunk
+ $ bzr fast-import projectx.fi trunk
+
+Subversion Conversion
+---------------------
+
+As the most common centralized version control system, migration from
+Subversion is particularly important for any *new* version control system.
+Bazaar's `svn`_ plugin provides tools for interaction with Subversion
+projects. In fact, Bazaar can be used transparently with projects stored in
+Subversion, but that is beyond the scope of this document. (See
+http://doc.bazaar.canonical.com/migration/en/foreign/bzr-on-svn-projects.html for
+more on that subject.) What is relevant here is the ``svn-import`` command
+provided by that plugin. This can import an entire subversion repository
+including tags and branches, particularly if they are stored in Subversion's
+recommended directory structure: ``/tags/``, ``/branches/`` and ``/trunk/``.
+
+This command has flexible ways to specify what paths within the Subversion
+repository contain branches and which contain tags. For example, the
+recommended layout for Subversion projects (called ``trunk`` by the svn
+plugin) could be specified in ``~/.bazaar/subversion.conf`` as
+
+::
+
+ [203ae883-c723-44c9-aabd-cb56e4f81c9a]
+ branches = branches/*
+ tags = tags/*
+
+This allows substantially complicated Subversion repositories to be converted
+into a set of separate Bazaar branches. After installing the svn plugin, see
+``bzr help svn-import`` and ``bzr help svn-layout``.
+
+.. _svn: http://launchpad.net/bzr-svn
+
+.. TODO: Legacy VCS to bzr sync. Tailor? Incremental conversions?
diff --git a/doc/en/admin-guide/other-setups.txt b/doc/en/admin-guide/other-setups.txt
new file mode 100644
index 0000000..b3e060f
--- /dev/null
+++ b/doc/en/admin-guide/other-setups.txt
@@ -0,0 +1,60 @@
+Other Setups
+============
+
+Dumb servers
+------------
+
+Bazaar can also serve branches over protocols that know nothing about Bazaar's
+specific needs. These are called "dumb servers" to distinguish them from
+Bazaar's native protocol. Currently HTTP, HTTPS, FTP, SFTP and HTTP+WebDAV can
+be used to read branches remotely. FTP, SFTP and HTTP+WebDAV can be used for
+writing as well. To use any of these protocols, it is just necessary to
+provide access to the server's filesystem under ``/srv/bzr``.
+
+For example, for Apache to provide read-only access to the branches
+in ``/srv/bzr`` the configuration may look like this::
+
+ Alias /code /srv/bzr
+ <Directory /srv/bzr>
+ Options Indexes
+ # ...
+ </Directory>
+
+and users could use the URL ``http://server.example.com/code/projectx/trunk``
+to refer to the trunk branch.
+
+Note that SFTP access is often available whenever there is SSH access and it
+may be a good choice when Bazaar cannot be installed on the server to allow
+``bzr+ssh://`` access. Dumb servers are slower by their very nature than the
+native protocol, but they can be a good choice in situations where the
+software and protocols that can be used on the server or the network is
+limited.
+
+Smart server over HTTP(S)
+-------------------------
+
+Bazaar can use its native protocol with HTTP or HTTPS requests. Since HTTP is
+a network protocol that is available on many networks, this can be a good
+option where SSH access is not possible. Another benefit of this setup is that
+all of the authentication and access control methods available to the HTTP
+server (basic, LDAP, ActiveDirectory, etc.) are then available to control
+access to Bazaar branches. More information about setting up this type of
+access using Apache and FastCGI or mod_python or WSGI is in the `smart server
+section of the User's Guide <../user-guide/http_smart_server.html>`_.
+
+Direct Smart Server Access
+--------------------------
+
+The built-in server that is used by ``bzr+ssh://`` access can also be used as a
+persistent server on a dedicated port. Bazaar's official port is 4155,
+although the port used can be configured. Further information on running the
+Bazaar smart server from inetd, or directly from the shell is in the `User's
+Guide <../user-guide/server.html#inetd>`_. The dedicated Bazaar server does
+not currently perform any authentication, so this server by default provides
+read-only access. It can be run with the ``--allow-writes`` option, but the
+smart server does not do any additional access control so this may allow
+undesired people to make changes to branches. (Which of course can be
+reverted.) If the user that runs the server has write access to the branches
+on the filesystem, then anyone with access to port 4155 on the server can make
+changes to the branches stored there.
+
diff --git a/doc/en/admin-guide/security.txt b/doc/en/admin-guide/security.txt
new file mode 100644
index 0000000..af9df7e
--- /dev/null
+++ b/doc/en/admin-guide/security.txt
@@ -0,0 +1,116 @@
+Security
+========
+
+Authentication
+--------------
+
+Bazaar's philosophy on authentication is that it is best to reuse existing
+authentication technologies, rather than trying to reinvent potentially
+complicated methods for securely identifying users. As such, we describe two
+such uses of existing software for authentication purposes.
+
+Using SSH
+~~~~~~~~~
+
+SSH is a very well tested and featureful technology for authenticating users.
+For situations where all of the developers have local accounts on the server,
+it is trivial to provide secure, authenticated ``bzr+ssh://`` access. One
+concern with this method is that it may not be desirable to grant shell access
+to developers on the server machine. In this case, Bazaar provides
+``bzr_ssh_path_limiter``, a script that runs the Bazaar smart server on the
+server machine at a specified path, and allows no other access.
+
+To set it up, specify::
+
+ command="/path/to/bzr_ssh_path_limiter <path>" <typical key line>
+
+in each user's ``~/.ssh/authorized_keys`` file on the server, where `<path>` is
+the path to limit access to (and its subdirectories). For more documentation
+on the syntax of the ``authorized_keys`` file see the documentation of the SSH
+server. This will only permit Bazaar access to the specified path and no other
+SSH access for that user.
+
+If it isn't desired to give each user an account on the server, multiple
+private/public key pairs can be included under one single SSH account (say
+sshuser) in the ``~sshuser/.ssh/authorized_keys`` file and then each developer
+can be given their own private key. They can then use
+``bzr+ssh://sshuser@server.example.com/`` URLs to access the server.
+
+Using HTTP authentication methods
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Access Control
+--------------
+
+Many projects need fine-grained access control on who may read and write to
+which branches. Incorporating these controls into OS-level user accounts
+using groups and filesystem permissions can be difficult or even not permitted
+in some instances. Bazaar provides a script called ``bzr_access`` that can be
+used to provide access control based on usernames, with authentication
+performed by SSH. To do so, we need to set up private-key authentication in
+SSH. This can be done using a single SSH user on the server, or one account
+per user. The idea is to use the SSH's ``authorized_keys`` file to specify
+the ``bzr_access`` script as the only command that can be run by a user
+identified by a particular key pair.
+
+First, you will need to generate a private/public key pair for each user who
+will be accessing the repository. The private key should be distributed to
+the user and the public key will be needed on the server to identify the user.
+On the server, in the SSH user's ``~/.ssh/authorized_keys`` file, use the
+following line for each repository user and the corresponding public key::
+
+ command="/path/to/bzr_access /path/to/bzr /path/to/repository <username>",no- port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-<type> <key>
+
+where `<key>` is the (possibly very long) public key, `<type>` is the type of
+SSH key and `<username>` is the username to associate with that public key.
+
+The ``bzr_access`` script obtains its configuration information from the file
+``/path/to/repository/bzr_access.conf``. This file should not be placed under
+version control in a branch located at ``/path/to/repository`` since that
+would allow anyone with access to the repository to change the access control
+rules. The ``bzr_access.conf`` file is in a simple INI-style format with
+sections defined by ``[groups]`` and ``[/]``. The options in the ``[groups]``
+section are the names of groups and the values of those options should be the
+usernames in that group. Inside the ``[/]`` section, the options are
+usernames or group names (prefixed with ``@``) and the values are either
+``rw``, ``r`` or nothing, representing read-write access, read-only access or
+no access at all. A sample of ``bzr_access.conf`` could be::
+
+ [groups]
+ admins = alpha
+ devels = beta, gamma, delta
+
+ [/]
+ @admins = rw
+ @devels = r
+ upsilon =
+
+where the user whose key is associated with `alpha` would have read-write
+access, the users `beta`, `gamma` and `delta` would have read-only access and
+user `upsilon` would not be able to access any branches under
+``/path/to/repository``.
+
+Additional Considerations with ``bzr_access``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As currently written, ``bzr_access`` only allows each public key to be
+associated with a single repository location. This means that if developers
+need to access two or more different repositories, then each developer will
+need to have two or more private keys for SSH and be able to select between
+them (see ``man ssh`` for more information on configuring multiple private
+keys).
+
+Also, each repository can only have a single configuration file, with access
+configured for all branches in the repository. This means that if different
+access rules are needed for different projects, then those projects must be in
+different repositories. This then necessitates the use of multiple private
+keys as just described.
+
+Finally, as noted above under `Using SSH`_ all of the public keys may be
+included in the ``authorized_keys`` file of a single user on the server. It
+is also possible to use a single private/public key pair for all of the
+developers, but this only allows a single username for access control to the
+repository (since the username is associated with the public key in
+``authorized_keys``. While this is certainly possible it seems to defeat the
+purpose of fine-grained access control, although it does provide the same
+limited SSH access as that described above.
diff --git a/doc/en/admin-guide/simple-setups.txt b/doc/en/admin-guide/simple-setups.txt
new file mode 100644
index 0000000..b65383d
--- /dev/null
+++ b/doc/en/admin-guide/simple-setups.txt
@@ -0,0 +1,142 @@
+Simple Setups
+=============
+
+Consider the following simple scenario where we will be serving Bazaar branches
+that live on a single server. Those branches are in the subdirectories of
+``/srv/bzr`` (or ``C:\bzr``) and they will all be related to a single project
+called "ProjectX". ProjectX will have a trunk branch and at least one feature
+branch. As we get further, we will consider other scenarios, but this will be
+a sufficiently motivating example.
+
+Smart server
+------------
+
+The simplest possible setup for providing outside access to the branches on
+the server uses Bazaar's built-in smart server tunneled over SSH_ so
+that people who can access your server using SSH can have read and write
+access to branches on the server. This setup uses the authentication
+mechanisms of SSH including private keys, and the access control mechanisms of
+the server's operating system. In particular, using groups on the server, it
+is possible to provide different access privileges to different groups of
+developers.
+
+.. _SSH: http://www.openssh.org/
+
+Setup
+~~~~~
+
+There is no setup required for this on the server, apart from having Bazaar
+installed and SSH access available to your developers. Using SSH
+configuration options it is possible to restrict developers from using
+anything *but* Bazaar on the server via SSH, and to limit what part of the
+file system they can access.
+
+Client
+~~~~~~
+
+Clients can access the branches using URLs with the ``bzr+ssh://`` prefix. For
+example, to get a local copy of the ProjectX trunk, a developer could do::
+
+ $ bzr branch bzr+ssh://server.example.com/srv/bzr/projectx/trunk projectx
+
+If the developers have write access to the ``/srv/bzr/projectx`` directory, then
+they can create new branches themselves using::
+
+ $ bzr branch bzr+ssh://server.example.com/srv/bzr/projectx/trunk \
+ bzr+ssh://server.example.com/srv/bzr/projectx/feature-gui
+
+Of course, if this isn't desired, then developers should not have write access
+to the ``/srv/bzr/projectx`` directory.
+
+Further Configuration
+~~~~~~~~~~~~~~~~~~~~~
+
+For a project with multiple branches that are all related, it is best to use a
+shared repository to hold all of the branches. To set this up, do::
+
+ $ cd /srv/bzr
+ $ bzr init-repo --no-trees projectx
+
+The ``--no-trees`` option saves space by not creating a copy of the working
+files on the server's filesystem. Then, any branch created under
+``/srv/bzr/projectx`` (see `Migration <migration.html>`_ for some ways to do
+this) will share storage space, which is particularly helpful for branches that
+have many revisions in common, such as a project trunk and its feature
+branches.
+
+If Bazaar is not installed on the user's path or not specified in the SSH
+configuration, then a path can be specified from the client with the
+``BZR_REMOTE_PATH`` environment variable. For example, if the Bazaar executable
+is installed in ``/usr/local/bzr-2.0/bin/bzr``, then a developer could use::
+
+ $ BZR_REMOTE_PATH=/usr/local/bzr-2.0/bin/bzr bzr info \
+ bzr+ssh://server.example.com/srv/bzr/proectx/trunk
+
+to get information about the trunk branch. The remote path can also be
+specified in Bazaar's configuration files for a particular location. See
+``bzr help configuration`` for more details.
+
+If developers have home directories on the server, they can use ``/~/`` in
+URLs to refer to their home directory. They can also use ``/~username/`` to
+refer to the home directory of user ``username``. For example, if there are two
+developers ``alice`` and ``bob``, then Bob could use::
+
+ $ bzr log bzr+ssh://server.example.com/~/fix-1023
+
+to refer to one of his bug fix branches and::
+
+ $ bzr log bzr+ssh://server.example.com/~alice/fix-2047
+
+to refer to one of Alice's branches. [#]_
+
+.. [#] The version of Bazaar installed on the server must be at least 2.1.0b1
+ or newer to support ``/~/`` in bzr+ssh URLs.
+
+Using a restricted SSH account to host multiple users and repositories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once you have a bzr+ssh setup using a shared repository you may want to share
+that repository among a small set of developers. Using shared SSH access enables
+you to complete this task without any complicated setup or ongoing management.
+
+To allow multiple users to access Bazaar over ssh we can allow ssh access to a common
+account that only allows users to run a specific command. Using a single account
+simplifies deployment as no permissions management issues exist for the filesystem.
+All users are the same user at the server level. Bazaar labels the commits with
+each users details so seperate server accounts are not required.
+
+To enable this configuration we update the ``~/.ssh/authorized_keys`` to include
+command restrictions for connecting users.
+
+In these examples the user will be called ``bzruser``.
+
+The following example shows how a single line is configured::
+
+ command="bzr serve --inet --allow-writes --directory=/srv/bzr",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= my bzr key
+
+This command allows the user to access only bzr and disables other SSH use. Write
+access to each repository in the directory ``/srv/bzr`` has been granted with ``--allow-writes``
+and can be removed for individual users that should only require read access. The root of
+the directory structure can be altered for each user to allow them to see only a subet
+of the repositories available. The example below assumes two seperate repositories
+for Alice and Bob. This method will not allow you to restrict access to part
+of a repository, you may only restrict access to a single part of the directory structure::
+
+ command="bzr serve --inet --allow-writes --directory=/srv/bzr/alice/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= Alice's SSH Key
+ command="bzr serve --inet --allow-writes --directory=/srv/bzr/bob/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= Bob's SSH Key
+ command="bzr serve --inet --allow-writes --directory=/srv/bzr/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= Repo Manager SSH Key
+
+Alice and Bob have access to their own repository and Repo Manager
+has access to the each of their repositories. Users are not allowed access to any part of
+the system except the directory specified. The bzr+ssh urls are simplified by
+serving using ``bzr serve`` and the ``--directory`` option.
+
+If Alice logs in she uses the following command for her fix-1023 branch::
+
+ $ bzr log bzr+ssh://bzruser@server.example.com/fix-1023
+
+If Repo Manager logs in he uses the following command to access Alice's
+fix-1023::
+
+ $ bzr log bzr+ssh://bzruser@server.example.com/alice/fix-1023
+
diff --git a/doc/en/admin-guide/upgrade.txt b/doc/en/admin-guide/upgrade.txt
new file mode 100644
index 0000000..d823abf
--- /dev/null
+++ b/doc/en/admin-guide/upgrade.txt
@@ -0,0 +1,77 @@
+Upgrades
+========
+
+Bazaar has a strong commitment to inter-version compatibility both on disk and
+over the network. Newer clients should be able to interact with older
+versions on the server (although perhaps not at optimal speed) and older
+clients should also be able to communicate with newer versions of Bazaar on
+the server. Divergences from this rule are considered bugs and are fixed in
+later versions.
+
+That said, Bazaar is constantly improving and the most recent versions are the
+most featureful and have better performance. In particular, the Bazaar
+versions 2.0 and later have significant advantages over earlier versions,
+including a more compact disk format, faster network operations and overall
+performance improvements. With the 2.0 release, Bazaar has moved to a
+stable/development release model where the 2.x series is maintained with
+bugfixes releases for six months, while simultaneously the 2.(x+1) series is
+being developed with monthly beta releases that are suitable for everyday use.
+Bazaar development has a stable trunk with an extensive test suite, so there
+is no reason to fear using the development series for everyday use, it simply
+changes more often than the stable series. Many users do run the development
+version of Bazaar and update it regularly, including most of the Bazaar
+developers themselves.
+
+
+Software upgrades
+-----------------
+
+Upgrading the Bazaar software is as simple as re-installing the Python package
+using either the latest binary package for Windows or Mac OS X, the binary
+package provided by your GNU/Linux distribution, or installing from the source
+release. See http://wiki.bazaar.canonical.com/Downloads for the latest
+releases for all supported platforms.
+
+Bazaar's later versions support all of the earlier disk formats (back to the
+very first one), so there is no need to upgrade the branches on the disk when
+upgrading the software. To make use of particular new features that might
+need updated versions on both the server and developer's machines, it does not
+matter if the clients or the servers are upgraded first.
+
+
+Disk format upgrades
+--------------------
+
+In its evolution, Bazaar has used a sequence of disk formats for improved
+storage efficiency and speed. With the new disk format released in version
+2.0, there is a commitment to keep that disk format until version 3.0 is
+released, which has not even been planned yet. (Bazaar 2.0 was released
+almost two years after Bazaar 1.0.) As a result, disk format upgrades should
+be extremely infrequent.
+
+If there are existing branches in an older format that you would like to
+upgrade to the latest format, you can see the `2.0 Upgrade Guide
+<../upgrade-guide/index.html>`_ for more information. From the system
+administration perspective, it is important to coordinate the timing of
+various upgrades in the process. First, the central branches on the server
+should be upgraded. Next, any local mirrors that developers have should be
+upgraded. Finally, developers' local branches should be upgraded. These
+upgrades will require an appropriate version of the software whenever they are
+performed. (It is possible to upgrade branches remotely over the network, but
+it may be much slower.)
+
+
+Plugin upgrades
+---------------
+
+When Bazaar does update its version, plugins that use the Bazaar API may need
+to be upgraded to reflect changes in that API. Some plugins have strict
+version dependencies on the version of the Bazaar API that they will accept.
+If this is the case, then you should ensure that the plugins you depend on
+have been updated *before* you upgrade your Bazaar version to avoid a
+situation where your plugins won't work with the installed version of Bazaar.
+If this does happen, then the solution is simply to reinstall the previous
+version of Bazaar that *did* work with the plugins. For installations that
+depend on a large number of plugins, this sort of version upgrade should be
+tested in a safe sandbox to ensure that the entire collection of Bazaar and
+its plugins can all work together.
diff --git a/doc/en/conf.py b/doc/en/conf.py
new file mode 100644
index 0000000..48083b4
--- /dev/null
+++ b/doc/en/conf.py
@@ -0,0 +1,106 @@
+# -*- coding: utf-8 -*-
+#
+# Bazaar documentation build configuration file, created by
+# sphinx-quickstart on Tue Jul 21 17:04:52 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path = [os.path.abspath('../..')] + sys.path
+
+# Most of the configuration for Bazaar docs is defined here ...
+from bzrlib.doc_generate.conf import *
+
+## Configuration specific to this site ##
+
+# The locale code for this documentation set
+bzr_locale = 'en'
+
+# Translations & supporting helper function
+bzr_titles = {
+ u'Table of Contents (%s)': None,
+ u'Bazaar User Guide': None,
+ u'Bazaar User Reference': None,
+ u'Bazaar Release Notes': None,
+ u'Bazaar Upgrade Guide': None,
+ u"Bazaar System Administrator's Guide": None,
+ u'Bazaar in five minutes': None,
+ u'Bazaar Tutorial': None,
+ u'Using Bazaar With Launchpad': None,
+ u'Centralized Workflow Tutorial': None,
+ u"What's New in Bazaar 2.1?": None,
+ }
+def bzr_title(s):
+ return bzr_titles.get(s) or s
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+html_short_title = bzr_title(u"Table of Contents (%s)") % (release,)
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+html_additional_pages = {'index': 'index.html'}
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'bzr-%s' % (bzr_locale,)
+
+# Grouping the document tree into files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+bzr_documents = [
+ # Manuals
+ ('user-guide/index', 'bzr-%s-user-guide' % (bzr_locale,),
+ bzr_title(u'Bazaar User Guide'), bzr_team, 'manual'),
+ ('user-reference/index', 'bzr-%s-user-reference' % (bzr_locale,),
+ bzr_title(u'Bazaar User Reference'), bzr_team, 'manual'),
+ ('release-notes/index', 'bzr-%s-release-notes' % (bzr_locale,),
+ bzr_title(u'Bazaar Release Notes'), bzr_team, 'manual'),
+ ('upgrade-guide/index', 'bzr-%s-upgrade-guide' % (bzr_locale,),
+ bzr_title(u'Bazaar Upgrade Guide'), bzr_team, 'manual'),
+ ('admin-guide/index', 'bzr-%s-admin-guide' % (bzr_locale,),
+ bzr_title(u"Bazaar System Administrator's Guide"), bzr_team, 'manual'),
+ # Tutorials
+ ('mini-tutorial/index', 'bzr-%s-tutorial-mini' % (bzr_locale,),
+ bzr_title(u'Bazaar in five minutes'), bzr_team, 'howto'),
+ ('tutorials/tutorial', 'bzr-%s-tutorial' % (bzr_locale,),
+ bzr_title(u'Bazaar Tutorial'), bzr_team, 'howto'),
+ ('tutorials/using_bazaar_with_launchpad',
+ 'bzr-%s-tutorial-with-launchpad' % (bzr_locale,),
+ bzr_title(u'Using Bazaar With Launchpad'), bzr_team, 'howto'),
+ ('tutorials/centralized_workflow',
+ 'bzr-%s-tutorial-centralized' % (bzr_locale,),
+ bzr_title(u'Centralized Workflow Tutorial'), bzr_team, 'howto'),
+ ('whats-new/whats-new-in-2.1', 'bzr-%s-whats-new' % (bzr_locale,),
+ bzr_title(u"What's New in Bazaar 2.1?"), bzr_team, 'howto'),
+]
+
+latex_documents = [
+ (start, target+'.tex', title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+texinfo_documents = [
+ (start, target, title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+# List of documents that shouldn't be included in the build.
+unused_docs = [
+ # Subtopics that get included
+ 'upgrade-guide/overview',
+ 'upgrade-guide/data_migration',
+ 'upgrade-guide/tips_and_tricks',
+ # Plain-style documentation generation stuff
+ 'release-notes/NEWS',
+ 'user-reference/bzr_man',
+ 'user-guide/index-plain',
+ 'admin-guide/index-plain',
+ # Templates
+ 'release-notes/release-template',
+ 'release-notes/series-template',
+ # Miscellaneous
+ 'user-reference/readme',
+]
+
diff --git a/doc/en/index.txt b/doc/en/index.txt
new file mode 100644
index 0000000..fff6cbe
--- /dev/null
+++ b/doc/en/index.txt
@@ -0,0 +1,20 @@
+.. Bazaar documentation master file, created by
+ sphinx-quickstart on Tue Jul 21 17:04:52 2009.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+
+Table of Contents
+=================
+
+.. toctree::
+ :maxdepth: 1
+
+ whats-new/whats-new-in-2.6
+ user-guide/index
+ tutorials/index
+ quick-reference/index
+ release-notes/index
+ upgrade-guide/index
+ user-reference/index
+ admin-guide/index
diff --git a/doc/en/make.bat b/doc/en/make.bat
new file mode 100644
index 0000000..7846ff6
--- /dev/null
+++ b/doc/en/make.bat
@@ -0,0 +1,112 @@
+@ECHO OFF
+
+REM Command file for Sphinx documentation
+
+set SPHINXBUILD=sphinx-build
+set ALLSPHINXOPTS=-d _build/doctrees %SPHINXOPTS% .
+if NOT "%PAPER%" == "" (
+ set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
+)
+
+if "%1" == "" goto help
+
+if "%1" == "help" (
+ :help
+ echo.Please use `make ^<target^>` where ^<target^> is one of
+ echo. html to make standalone HTML files
+ echo. dirhtml to make HTML files named index.html in directories
+ echo. pickle to make pickle files
+ echo. json to make JSON files
+ echo. htmlhelp to make HTML files and a HTML help project
+ echo. qthelp to make HTML files and a qthelp project
+ echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter
+ echo. changes to make an overview over all changed/added/deprecated items
+ echo. linkcheck to check all external links for integrity
+ echo. doctest to run all doctests embedded in the documentation if enabled
+ goto end
+)
+
+if "%1" == "clean" (
+ for /d %%i in (_build\*) do rmdir /q /s %%i
+ del /q /s _build\*
+ goto end
+)
+
+if "%1" == "html" (
+ %SPHINXBUILD% -b html %ALLSPHINXOPTS% _build/html
+ echo.
+ echo.Build finished. The HTML pages are in _build/html.
+ goto end
+)
+
+if "%1" == "dirhtml" (
+ %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% _build/dirhtml
+ echo.
+ echo.Build finished. The HTML pages are in _build/dirhtml.
+ goto end
+)
+
+if "%1" == "pickle" (
+ %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% _build/pickle
+ echo.
+ echo.Build finished; now you can process the pickle files.
+ goto end
+)
+
+if "%1" == "json" (
+ %SPHINXBUILD% -b json %ALLSPHINXOPTS% _build/json
+ echo.
+ echo.Build finished; now you can process the JSON files.
+ goto end
+)
+
+if "%1" == "htmlhelp" (
+ %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% _build/htmlhelp
+ echo.
+ echo.Build finished; now you can run HTML Help Workshop with the ^
+.hhp project file in _build/htmlhelp.
+ goto end
+)
+
+if "%1" == "qthelp" (
+ %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% _build/qthelp
+ echo.
+ echo.Build finished; now you can run "qcollectiongenerator" with the ^
+.qhcp project file in _build/qthelp, like this:
+ echo.^> qcollectiongenerator _build\qthelp\Bazaar.qhcp
+ echo.To view the help file:
+ echo.^> assistant -collectionFile _build\qthelp\Bazaar.ghc
+ goto end
+)
+
+if "%1" == "latex" (
+ %SPHINXBUILD% -b latex %ALLSPHINXOPTS% _build/latex
+ echo.
+ echo.Build finished; the LaTeX files are in _build/latex.
+ goto end
+)
+
+if "%1" == "changes" (
+ %SPHINXBUILD% -b changes %ALLSPHINXOPTS% _build/changes
+ echo.
+ echo.The overview file is in _build/changes.
+ goto end
+)
+
+if "%1" == "linkcheck" (
+ %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% _build/linkcheck
+ echo.
+ echo.Link check complete; look for any errors in the above output ^
+or in _build/linkcheck/output.txt.
+ goto end
+)
+
+if "%1" == "doctest" (
+ %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% _build/doctest
+ echo.
+ echo.Testing of doctests in the sources finished, look at the ^
+results in _build/doctest/output.txt.
+ goto end
+)
+
+:end
diff --git a/doc/en/mini-tutorial/index.txt b/doc/en/mini-tutorial/index.txt
new file mode 100644
index 0000000..9e48d17
--- /dev/null
+++ b/doc/en/mini-tutorial/index.txt
@@ -0,0 +1,256 @@
+======================
+Bazaar in five minutes
+======================
+
+Introduction
+============
+
+Bazaar is a distributed version control system that makes it easier for
+people to work together on software projects.
+
+Over the next five minutes, you'll learn how to put your files under
+version control, how to record changes to them, examine your work, publish
+it and send your work for merger into a project's trunk.
+
+
+Installation
+============
+
+This guide doesn't describe how to install Bazaar but it's usually very
+easy. You can find installation instructions at:
+
+- **GNU/Linux:** Bazaar is probably in your GNU/Linux distribution already.
+- **Windows:** `installation instructions for Windows`_.
+- **Mac OS X:** `installation instructions for Mac OS X`_.
+
+For other platforms and to install from source code, see the Download_
+and Installation_ pages.
+
+.. _installation instructions for Windows: http://wiki.bazaar.canonical.com/WindowsDownloads
+.. _installation instructions for Mac OS X: http://wiki.bazaar.canonical.com/MacOSXBundle
+.. _Download: http://wiki.bazaar.canonical.com/Download
+.. _Installation: http://wiki.bazaar.canonical.com/InstallationFaq
+
+
+Introducing yourself
+====================
+
+Bazaar records changes to source code, and it records who made the change.
+The person is identified by their name and email address. (If you're
+concerned about spam, you don't need to use a real address that you
+actually read, but the convention is that it looks like an email address.)
+
+Before you start working, let's tell Bazaar who you are. Using your name
+and email address, instead of John Doe's, type::
+
+ $ bzr whoami "John Doe <john.doe@gmail.com>"
+
+You can check what identity is stored in Bazaar's configuration::
+
+ $ bzr whoami
+ John Doe <john.doe@gmail.com>
+
+
+Starting a new project
+======================
+
+Let's suppose we want to store a new project under Bazaar. First, we'll
+make a *repository directory* to hold all our work related to this
+project, where developers can create branches to test development of
+specific features or, more generally, modifications to the working file
+set.
+
+After creating the repository, change to that directory, and create the
+project's main trunk branch.
+
+::
+
+ $ bzr init-repo sample
+ Shared repository with trees (format: 2a)
+ Location:
+ shared repository: sample
+ $ bzr init sample/trunk
+ $ cd sample/trunk
+ Created a repository tree (format: 2a)                                         
+ Using shared repository: /home/john/sample/
+
+
+Adding files
+============
+
+Now that we have the trunk, we need to move to that directory and
+create some example files for the first version of that project. Create
+a file ``test1.txt`` using a text editor (like emacs, nano, or notepad),
+and save it. Then we'll "add" the file, which tells bzr we want it to
+track changes::
+
+ bzr add test1.txt
+
+and then commit, which saves a snapshot of all versioned files::
+
+ bzr commit -m "Added first line of text"
+
+
+Making changes to your files
+============================
+
+
+Let's change a file and commit that change to your branch.
+
+Edit ``test1.txt`` in your favourite editor, then use ``bzr add`` to tell bzr
+to track changes to this file ::
+
+ $ echo test test test > test1.txt
+ $ bzr add test1.txt
+ adding test1.txt
+
+`bzr diff` shows the changes between the last revision in this branch, and your
+current tree (or, with the ``-r`` option, between any two trees). ::
+
+ $ bzr diff
+ === modified file 'test1.txt'
+ --- test1.txt 2007-10-08 17:56:14 +0000
+ +++ test1.txt 2007-10-08 17:46:22 +0000
+ @@ -0,0 +1,1 @@
+ +test test test
+
+Commit your work to the Bazaar branch::
+
+ $ bzr commit -m "Added first line of text"
+ Committing to: /home/john/sample/trunk/                             
+ added test1.txt
+ Committed revision 1.
+
+Viewing the revision log
+========================
+
+You can see the history of your branch by browsing its log::
+
+ $ bzr log
+ revno: 1
+ committer: John Doe <john.doe@gmail.com>
+ branch nick: trunk
+ timestamp: Mon 2006-10-08 17:46:22 +0000
+ message:
+ Initial import
+
+
+Publishing your branch on Launchpad
+===================================
+
+Launchpad is a suite of development and hosting tools for
+software projects. You can use it to publish your branch. (You can
+also publish branches onto your own server or other hosting services.)
+
+The steps to publishing branches on Launchpad are:
+
+1. Create a Launchpad account: visit the `Launchpad login page`_ and choose to create a new account.
+
+.. _Launchpad login page: https://launchpad.net/+login
+
+2. Bazaar uses the SSH encryption and authentication protocol to connect
+ to Launchpad. You need to first `create an SSH key`_ on your own computer,
+ by running the command::
+
+ $ ssh-keygen
+
+.. _create an SSH key: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair
+
+3. `Upload your SSH public key to Launchpad`_.
+
+.. _Upload your SSH public key to Launchpad: https://launchpad.net/~/+editsshkeys
+
+4. `Make a team for your project`_. Even if you're starting as the only
+ developer on this project, creating a new now will let you more easily
+ add other people later.
+
+.. _Make a team for your project: https://help.launchpad.net/Teams/CreatingAndRunning
+
+5. `Create a project`_.
+
+.. _Create a project: https://help.launchpad.net/Projects/Registering
+
+6. Tell Bazaar your Launchpad account name. If your account is john.doe, type ::
+
+ $ bzr launchpad-login john.doe
+
+7. `Push the branch for your project`_. Once you've committed your changes
+ locally, you can publish them as the trunk of your new project by saying
+
+ $ bzr push lp:~sample-developers/sample/trunk
+
+ (Of course, using the team and project names you just chose.)
+
+.. _Push the branch for your project: https://help.launchpad.net/Code/UploadingABranch
+
+Creating your own copy of another branch
+========================================
+
+To work with someone else's code, you can make your own copy of their
+branch. Let's take a real-world example, Bazaar's GTK interface::
+
+ $ bzr init-repo ~/bzr-gtk
+ $ bzr branch lp:~bzr/bzr-gtk/trunk ~/bzr-gtk/john
+ Branched 292 revision(s).
+
+Bazaar will download all the files and complete revision history from the
+bzr-gtk project's trunk branch and create a copy called ``john``.
+
+Now, you have your own copy of the branch and can commit changes with
+or without a net connection. You can share your branch at any time by
+publishing it and, if the bzr-gtk team want to use your work, Bazaar
+makes it easy for them to merge your branch back into their trunk branch.
+
+
+Updating your branch from the main branch
+=========================================
+
+While you commit changes to your branch, it's likely that other people will
+also continue to commit code to the parent branch.
+
+To make sure your branch stays up to date, you should merge changes from
+the parent into your personal branch::
+
+ $ bzr merge
+ Merging from saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
+ All changes applied successfully.
+
+Check what has changed::
+
+ $ bzr diff
+
+If different branches have made changes to the same areas of the same
+files, then merging them may generate conflicts. When this happens,
+Bazaar puts text markers like ``<<<<<<<`` into the files, and records them
+in a list of conflicted files. You should edit the files to reflect the
+way you want to resolve the conflicts, use ``bzr diff`` to check the
+changes, and then ``bzr resolve`` to mark them as resolved.
+
+If you're happy with the changes, you can commit them to your personal
+branch::
+
+ $ bzr commit -m "Merge from main branch"
+ Committed revision 295.
+
+
+Learning more
+=============
+
+You can find out more about Bazaar in the
+`Bazaar User Guide <../user-guide/index.html>`_.
+
+To learn about Bazaar on the command-line::
+
+ $ bzr help
+
+To learn about the ''foo'' topic or command::
+
+ $ bzr help foo
+
+Licence
+=======
+
+Copyright 2007-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
diff --git a/doc/en/quick-reference/index.txt b/doc/en/quick-reference/index.txt
new file mode 100644
index 0000000..b001ad7
--- /dev/null
+++ b/doc/en/quick-reference/index.txt
@@ -0,0 +1,6 @@
+Quick Reference
+===============
+
+* `PDF format <../_static/en/bzr-en-quick-reference.pdf>`_
+* `PNG format <../_static/en/bzr-en-quick-reference.png>`_
+* `SVG format <../_static/en/bzr-en-quick-reference.svg>`_
diff --git a/doc/en/release-notes/bzr-0.1.txt b/doc/en/release-notes/bzr-0.1.txt
new file mode 100644
index 0000000..462d0ec
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.1.txt
@@ -0,0 +1,753 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.1.1
+#########
+
+:Released: 2005-10-12
+
+Bug Fixes
+*********
+
+* Fix problem in pulling over HTTP from machines that do not
+ allow directories to be listed.
+
+* Avoid harmless warning about invalid hash cache after
+ upgrading branch format.
+
+Performance
+***********
+
+* Avoid some unnecessary HTTP operations in branch and pull.
+
+
+bzr 0.1
+#######
+
+:Released: 2005-10-11
+
+Notes
+*****
+
+* 'bzr branch' over HTTP initially gives a very high estimate
+ of completion time but it should fall as the first few
+ revisions are pulled in. branch is still slow on
+ high-latency connections.
+
+Bug Fixes
+*********
+
+* bzr-man.py has been updated to work again. Contributed by
+ Rob Weir.
+
+* Locking is now done with fcntl.lockf which works with NFS
+ file systems. Contributed by Harald Meland.
+
+* When a merge encounters a file that has been deleted on
+ one side and modified on the other, the old contents are
+ written out to foo.BASE and foo.SIDE, where SIDE is this
+ or OTHER. Contributed by Aaron Bentley.
+
+* Export was choosing incorrect file paths for the content of
+ the tarball, this has been fixed by Aaron Bentley.
+
+* Commit will no longer commit without a log message, an
+ error is returned instead. Contributed by Jelmer Vernooij.
+
+* If you commit a specific file in a sub directory, any of its
+ parent directories that are added but not listed will be
+ automatically included. Suggested by Michael Ellerman.
+
+* bzr commit and upgrade did not correctly record new revisions
+ for files with only a change to their executable status.
+ bzr will correct this when it encounters it. Fixed by
+ Robert Collins
+
+* HTTP tests now force off the use of ``http_proxy`` for the duration.
+ Contributed by Gustavo Niemeyer.
+
+* Fix problems in merging weave-based branches that have
+ different partial views of history.
+
+* Symlink support: working with symlinks when not in the root of a
+ bzr tree was broken, patch from Scott James Remnant.
+
+Improvements
+************
+
+* 'branch' now accepts a --basis parameter which will take advantage
+ of local history when making a new branch. This allows faster
+ branching of remote branches. Contributed by Aaron Bentley.
+
+* New tree format based on weave files, called version 5.
+ Existing branches can be upgraded to this format using
+ 'bzr upgrade'.
+
+* Symlinks are now versionable. Initial patch by
+ Erik Toubro Nielsen, updated to head by Robert Collins.
+
+* Executable bits are tracked on files. Patch from Gustavo
+ Niemeyer.
+
+* 'bzr status' now shows unknown files inside a selected directory.
+ Patch from Heikki Paajanen.
+
+* Merge conflicts are recorded in .bzr. Two new commands 'conflicts'
+ and 'resolve' have needed added, which list and remove those
+ merge conflicts respectively. A conflicted tree cannot be committed
+ in. Contributed by Aaron Bentley.
+
+* 'rm' is now an alias for 'remove'.
+
+* Stores now split out their content in a single byte prefixed hash,
+ dropping the density of files per directory by 256. Contributed by
+ Gustavo Niemeyer.
+
+* 'bzr diff -r branch:URL' will now perform a diff between two branches.
+ Contributed by Robert Collins.
+
+* 'bzr log' with the default formatter will show merged revisions,
+ indented to the right. Initial implementation contributed by Gustavo
+ Niemeyer, made incremental by Robert Collins.
+
+
+Internals
+*********
+
+* Test case failures have the exception printed after the log
+ for your viewing pleasure.
+
+* InventoryEntry is now an abstract base class, use one of the
+ concrete InventoryDirectory etc classes instead.
+
+* Branch raises an UnsupportedFormatError when it detects a
+ bzr branch it cannot understand. This allows for precise
+ handling of such circumstances.
+
+* Remove RevisionReference class; ``Revision.parent_ids`` is now simply a
+ list of their ids and ``parent_sha1s`` is a list of their corresponding
+ sha1s (for old branches only at the moment.)
+
+* New method-object style interface for Commit() and Fetch().
+
+* Renamed ``Branch.last_patch()`` to ``Branch.last_revision()``, since
+ we call them revisions not patches.
+
+* Move ``copy_branch`` to ``bzrlib.clone.copy_branch``. The destination
+ directory is created if it doesn't exist.
+
+* Inventories now identify the files which were present by
+ giving the revision *of that file*.
+
+* Inventory and Revision XML contains a version identifier.
+ This must be consistent with the overall branch version
+ but allows for more flexibility in future upgrades.
+
+Testing
+*******
+
+* Removed testsweet module so that tests can be run after
+ bzr installed by 'bzr selftest'.
+
+* 'bzr selftest' command-line arguments can now be partial ids
+ of tests to run, e.g. ``bzr selftest test_weave``
+
+bzr 0.0.9
+#########
+
+:Released: 2005-09-23
+
+Bug Fixes
+*********
+
+* Fixed "branch -r" option.
+
+* Fix remote access to branches containing non-compressed history.
+ (Robert Collins).
+
+* Better reliability of HTTP server tests. (John Arbash-Meinel)
+
+* Merge graph maximum distance calculation fix. (Aaron Bentley)
+
+* Various minor bug in windows support have been fixed, largely in the
+ test suite. Contributed by Alexander Belchenko.
+
+Improvements
+************
+
+* Status now accepts a -r argument to give status between chosen
+ revisions. Contributed by Heikki Paajanen.
+
+* Revision arguments no longer use +/-/= to control ranges, instead
+ there is a 'before' namespace, which limits the successive namespace.
+ For example '$ bzr log -r date:yesterday..before:date:today' will
+ select everything from yesterday and before today. Contributed by
+ Robey Pointer
+
+* There is now a bzr.bat file created by distutils when building on
+ Windows. Contributed by Alexander Belchenko.
+
+Internals
+*********
+
+* Removed uuid() as it was unused.
+
+* Improved 'fetch' code for pulling revisions from one branch into
+ another (used by pull, merged, etc.)
+
+
+bzr 0.0.8
+#########
+
+:Released: 2005-09-20
+
+
+Improvements
+************
+
+* Adding a file whose parent directory is not versioned will
+ implicitly add the parent, and so on up to the root. This means
+ you should never need to explictly add a directory, they'll just
+ get added when you add a file in the directory. Contributed by
+ Michael Ellerman.
+
+* Ignore ``.DS_Store`` (contains Mac metadata) by default.
+ (Nir Soffer)
+
+* If you set ``BZR_EDITOR`` in the environment, it is checked in
+ preference to EDITOR and the config file for the interactive commit
+ editing program. Related to this is a bugfix where a missing program
+ set in EDITOR would cause editing to fail, now the fallback program
+ for the operating system is still tried.
+
+* Files that are not directories/symlinks/regular files will no longer
+ cause bzr to fail, it will just ignore them by default. You cannot add
+ them to the tree though - they are not versionable.
+
+
+Internals
+*********
+
+* Refactor XML packing/unpacking.
+
+Bug Fixes
+*********
+
+* Fixed 'bzr mv' by Ollie Rutherfurd.
+
+* Fixed strange error when trying to access a nonexistent HTTP
+ branch.
+
+* Make sure that the hashcache gets written out if it can't be
+ read.
+
+
+Portability
+***********
+
+* Various Windows fixes from Ollie Rutherfurd.
+
+* Quieten warnings about locking; patch from Matt Lavin.
+
+
+bzr-0.0.7
+#########
+
+:Released: 2005-09-02
+
+New Features
+************
+
+* ``bzr shell-complete`` command contributed by Clint Adams to
+ help with intelligent shell completion.
+
+* New expert command ``bzr find-merge-base`` for debugging merges.
+
+
+Enhancements
+************
+
+* Much better merge support.
+
+* merge3 conflicts are now reported with markers like '<<<<<<<'
+ (seven characters) which is the same as CVS and pleases things
+ like emacs smerge.
+
+
+Bug Fixes
+*********
+
+* ``bzr upgrade`` no longer fails when trying to fix trees that
+ mention revisions that are not present.
+
+* Fixed bugs in listing plugins from ``bzr plugins``.
+
+* Fix case of $EDITOR containing options for the editor.
+
+* Fix log -r refusing to show the last revision.
+ (Patch from Goffredo Baroncelli.)
+
+
+Changes
+*******
+
+* ``bzr log --show-ids`` shows the revision ids of all parents.
+
+* Externally provided commands on your $BZRPATH no longer need
+ to recognize --bzr-usage to work properly, and can just handle
+ --help themselves.
+
+
+Library
+*******
+
+* Changed trace messages to go through the standard logging
+ framework, so that they can more easily be redirected by
+ libraries.
+
+
+
+bzr-0.0.6
+#########
+
+:Released: 2005-08-18
+
+New Features
+************
+
+* Python plugins, automatically loaded from the directories on
+ ``BZR_PLUGIN_PATH`` or ``~/.bzr.conf/plugins`` by default.
+
+* New 'bzr mkdir' command.
+
+* Commit mesage is fetched from an editor if not given on the
+ command line; patch from Torsten Marek.
+
+* ``bzr log -m FOO`` displays commits whose message matches regexp
+ FOO.
+
+* ``bzr add`` with no arguments adds everything under the current directory.
+
+* ``bzr mv`` does move or rename depending on its arguments, like
+ the Unix command.
+
+* ``bzr missing`` command shows a summary of the differences
+ between two trees. (Merged from John Arbash-Meinel.)
+
+* An email address for commits to a particular tree can be
+ specified by putting it into .bzr/email within a branch. (Based
+ on a patch from Heikki Paajanen.)
+
+
+Enhancements
+************
+
+* Faster working tree operations.
+
+
+Changes
+*******
+
+* 3rd-party modules shipped with bzr are copied within the bzrlib
+ python package, so that they can be installed by the setup
+ script without clashing with anything already existing on the
+ system. (Contributed by Gustavo Niemeyer.)
+
+* Moved plugins directory to bzrlib/, so that there's a standard
+ plugin directory which is not only installed with bzr itself but
+ is also available when using bzr from the development tree.
+ ``BZR_PLUGIN_PATH`` and ``DEFAULT_PLUGIN_PATH`` are then added to the
+ standard plugins directory.
+
+* When exporting to a tarball with ``bzr export --format tgz``, put
+ everything under a top directory rather than dumping it into the
+ current directory. This can be overridden with the ``--root``
+ option. Patch from William Dodé and John Meinel.
+
+* New ``bzr upgrade`` command to upgrade the format of a branch,
+ replacing ``bzr check --update``.
+
+* Files within store directories are no longer marked readonly on
+ disk.
+
+* Changed ``bzr log`` output to a more compact form suggested by
+ John A Meinel. Old format is available with the ``--long`` or
+ ``-l`` option, patched by William Dodé.
+
+* By default the commit command refuses to record a revision with
+ no changes unless the ``--unchanged`` option is given.
+
+* The ``--no-plugins``, ``--profile`` and ``--builtin`` command
+ line options must come before the command name because they
+ affect what commands are available; all other options must come
+ after the command name because their interpretation depends on
+ it.
+
+* ``branch`` and ``clone`` added as aliases for ``branch``.
+
+* Default log format is back to the long format; the compact one
+ is available with ``--short``.
+
+
+Bug Fixes
+*********
+
+* Fix bugs in committing only selected files or within a subdirectory.
+
+
+bzr-0.0.5
+#########
+
+:Released: 2005-06-15
+
+Changes
+*******
+
+* ``bzr`` with no command now shows help rather than giving an
+ error. Suggested by Michael Ellerman.
+
+* ``bzr status`` output format changed, because svn-style output
+ doesn't really match the model of bzr. Now files are grouped by
+ status and can be shown with their IDs. ``bzr status --all``
+ shows all versioned files and unknown files but not ignored files.
+
+* ``bzr log`` runs from most-recent to least-recent, the reverse
+ of the previous order. The previous behaviour can be obtained
+ with the ``--forward`` option.
+
+* ``bzr inventory`` by default shows only filenames, and also ids
+ if ``--show-ids`` is given, in which case the id is the second
+ field.
+
+
+Enhancements
+************
+
+* New 'bzr whoami --email' option shows only the email component
+ of the user identification, from Jo Vermeulen.
+
+* New ``bzr ignore PATTERN`` command.
+
+* Nicer error message for broken pipe, interrupt and similar
+ conditions that don't indicate an internal error.
+
+* Add ``.*.sw[nop] .git .*.tmp *,v`` to default ignore patterns.
+
+* Per-branch locks keyed on ``.bzr/branch-lock``, available in
+ either read or write mode.
+
+* New option ``bzr log --show-ids`` shows revision and file ids.
+
+* New usage ``bzr log FILENAME`` shows only revisions that
+ affected that file.
+
+* Changed format for describing changes in ``bzr log -v``.
+
+* New option ``bzr commit --file`` to take a message from a file,
+ suggested by LarstiQ.
+
+* New syntax ``bzr status [FILE...]`` contributed by Bartosz
+ Oler. File may be in a branch other than the working directory.
+
+* ``bzr log`` and ``bzr root`` can be given an HTTP URL instead of
+ a filename.
+
+* Commands can now be defined by external programs or scripts
+ in a directory on $BZRPATH.
+
+* New "stat cache" avoids reading the contents of files if they
+ haven't changed since the previous time.
+
+* If the Python interpreter is too old, try to find a better one
+ or give an error. Based on a patch from Fredrik Lundh.
+
+* New optional parameter ``bzr info [BRANCH]``.
+
+* New form ``bzr commit SELECTED`` to commit only selected files.
+
+* New form ``bzr log -r FROM:TO`` shows changes in selected
+ range; contributed by John A Meinel.
+
+* New option ``bzr diff --diff-options 'OPTS'`` allows passing
+ options through to an external GNU diff.
+
+* New option ``bzr add --no-recurse`` to add a directory but not
+ their contents.
+
+* ``bzr --version`` now shows more information if bzr is being run
+ from a branch.
+
+
+Bug Fixes
+*********
+
+* Fixed diff format so that added and removed files will be
+ handled properly by patch. Fix from Lalo Martins.
+
+* Various fixes for files whose names contain spaces or other
+ metacharacters.
+
+
+Testing
+*******
+
+* Converted black-box test suites from Bourne shell into Python;
+ now run using ``./testbzr``. Various structural improvements to
+ the tests.
+
+* testbzr by default runs the version of bzr found in the same
+ directory as the tests, or the one given as the first parameter.
+
+* testbzr also runs the internal tests, so the only command
+ required to check is just ``./testbzr``.
+
+* testbzr requires python2.4, but can be used to test bzr running
+ under a different version.
+
+* Tests added for many other changes in this release.
+
+
+Internal
+********
+
+* Included ElementTree library upgraded to 1.2.6 by Fredrik Lundh.
+
+* Refactor command functions into Command objects based on HCT by
+ Scott James Remnant.
+
+* Better help messages for many commands.
+
+* Expose ``bzrlib.open_tracefile()`` to start the tracefile; until
+ this is called trace messages are just discarded.
+
+* New internal function ``find_touching_revisions()`` and hidden
+ command touching-revisions trace the changes to a given file.
+
+* Simpler and faster ``compare_inventories()`` function.
+
+* ``bzrlib.open_tracefile()`` takes a tracefilename parameter.
+
+* New AtomicFile class.
+
+* New developer commands ``added``, ``modified``.
+
+
+Portability
+***********
+
+* Cope on Windows on python2.3 by using the weaker random seed.
+ 2.4 is now only recommended.
+
+
+bzr-0.0.4
+#########
+
+:Released: 2005-04-22
+
+Enhancements
+************
+
+* 'bzr diff' optionally takes a list of files to diff. Still a bit
+ basic. Patch from QuantumG.
+
+* More default ignore patterns.
+
+* New 'bzr log --verbose' shows a list of files changed in the
+ changeset. Patch from Sebastian Cote.
+
+* Roll over ~/.bzr.log if it gets too large.
+
+* Command abbreviations 'ci', 'st', 'stat', '?' based on a patch
+ by Jason Diamon.
+
+* New 'bzr help commands' based on a patch from Denys Duchier.
+
+
+Changes
+*******
+
+* User email is determined by looking at $BZREMAIL or ~/.bzr.email
+ or $EMAIL. All are decoded by the locale preferred encoding.
+ If none of these are present user@hostname is used. The host's
+ fully-qualified name is not used because that tends to fail when
+ there are DNS problems.
+
+* New 'bzr whoami' command instead of username user-email.
+
+
+Bug Fixes
+*********
+
+* Make commit safe for hardlinked bzr trees.
+
+* Some Unicode/locale fixes.
+
+* Partial workaround for ``difflib.unified_diff`` not handling
+ trailing newlines properly.
+
+
+Internal
+********
+
+* Allow docstrings for help to be in PEP0257 format. Patch from
+ Matt Brubeck.
+
+* More tests in test.sh.
+
+* Write profile data to a temporary file not into working
+ directory and delete it when done.
+
+* Smaller .bzr.log with process ids.
+
+
+Portability
+***********
+
+* Fix opening of ~/.bzr.log on Windows. Patch from Andrew
+ Bennetts.
+
+* Some improvements in handling paths on Windows, based on a patch
+ from QuantumG.
+
+
+bzr-0.0.3
+#########
+
+:Released: 2005-04-06
+
+Enhancements
+************
+
+* New "directories" internal command lists versioned directories
+ in the tree.
+
+* Can now say "bzr commit --help".
+
+* New "rename" command to rename one file to a different name
+ and/or directory.
+
+* New "move" command to move one or more files into a different
+ directory.
+
+* New "renames" command lists files renamed since base revision.
+
+* New cat command contributed by janmar.
+
+Changes
+*******
+
+* .bzr.log is placed in $HOME (not pwd) and is always written in
+ UTF-8. (Probably not a completely good long-term solution, but
+ will do for now.)
+
+Portability
+***********
+
+* Workaround for difflib bug in Python 2.3 that causes an
+ exception when comparing empty files. Reported by Erik Toubro
+ Nielsen.
+
+Internal
+********
+
+* Refactored inventory storage to insert a root entry at the top.
+
+Testing
+*******
+
+* Start of shell-based black-box testing in test.sh.
+
+
+bzr-0.0.2.1
+###########
+
+Portability
+***********
+
+* Win32 fixes from Steve Brown.
+
+
+bzr-0.0.2
+#########
+
+:Codename: "black cube"
+:Released: 2005-03-31
+
+Enhancements
+************
+
+* Default ignore list extended (see bzrlib/__init__.py).
+
+* Patterns in .bzrignore are now added to the default ignore list,
+ rather than replacing it.
+
+* Ignore list isn't reread for every file.
+
+* More help topics.
+
+* Reinstate the 'bzr check' command to check invariants of the
+ branch.
+
+* New 'ignored' command lists which files are ignored and why;
+ 'deleted' lists files deleted in the current working tree.
+
+* Performance improvements.
+
+* New global --profile option.
+
+* Ignore patterns like './config.h' now correctly match files in
+ the root directory only.
+
+
+bzr-0.0.1
+#########
+
+:Released: 2005-03-26
+
+Enhancements
+************
+
+* More information from info command.
+
+* Can now say "bzr help COMMAND" for more detailed help.
+
+* Less file flushing and faster performance when writing logs and
+ committing to stores.
+
+* More useful verbose output from some commands.
+
+Bug Fixes
+*********
+
+* Fix inverted display of 'R' and 'M' during 'commit -v'.
+
+Portability
+***********
+
+* Include a subset of ElementTree-1.2.20040618 to make
+ installation easier.
+
+* Fix time.localtime call to work with Python 2.3 (the minimum
+ supported).
+
+
+bzr-0.0.0.69
+############
+
+:Released: 2005-03-22
+
+Enhancements
+************
+
+* First public release.
+
+* Storage of local versions: init, add, remove, rm, info, log,
+ diff, status, etc.
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.10.txt b/doc/en/release-notes/bzr-0.10.txt
new file mode 100644
index 0000000..caae988
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.10.txt
@@ -0,0 +1,90 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.10
+########
+
+:Released: 2006-08-29
+
+Improvements
+************
+* 'merge' now takes --uncommitted, to apply uncommitted changes from a
+ tree. (Aaron Bentley)
+
+* 'bzr add --file-ids-from' can be used to specify another path to use
+ for creating file ids, rather than generating all new ones. Internally,
+ the 'action' passed to ``smart_add_tree()`` can return ``file_ids`` that
+ will be used, rather than having bzrlib generate new ones.
+ (John Arbash Meinel, #55781)
+
+* ``bzr selftest --benchmark`` now allows a ``--cache-dir`` parameter.
+ This will cache some of the intermediate trees, and decrease the
+ setup time for benchmark tests. (John Arbash Meinel)
+
+* Inverse forms are provided for all boolean options. For example,
+ --strict has --no-strict, --no-recurse has --recurse (Aaron Bentley)
+
+* Serialize out Inventories directly, rather than using ElementTree.
+ Writing out a kernel sized inventory drops from 2s down to ~350ms.
+ (Robert Collins, John Arbash Meinel)
+
+Bug Fixes
+*********
+
+* Help diffutils 2.8.4 get along with binary tests (Marien Zwart: #57614)
+
+* Change LockDir so that if the lock directory doesn't exist when
+ ``lock_write()`` is called, an attempt will be made to create it.
+ (John Arbash Meinel, #56974)
+
+* ``bzr uncommit`` preserves pending merges. (John Arbash Meinel, #57660)
+
+* Active FTP transport now works as intended. (ghozzy, #56472)
+
+* Really fix mutter() so that it won't ever raise a UnicodeError.
+ It means it is possible for ~/.bzr.log to contain non UTF-8 characters.
+ But it is a debugging log, not a real user file.
+ (John Arbash Meinel, #56947, #53880)
+
+* Change Command handle to allow Unicode command and options.
+ At present we cannot register Unicode command names, so we will get
+ BzrCommandError('unknown command'), or BzrCommandError('unknown option')
+ But that is better than a UnicodeError + a traceback.
+ (John Arbash Meinel, #57123)
+
+* Handle TZ=UTC properly when reading/writing revisions.
+ (John Arbash Meinel, #55783, #56290)
+
+* Use ``GPG_TTY`` to allow gpg --cl to work with gpg-agent in a pipeline,
+ (passing text to sign in on stdin). (John Arbash Meinel, #54468)
+
+* External diff does the right thing for binaries even in foreign
+ languages. (John Arbash Meinel, #56307)
+
+* Testament handles more cases when content is unicode. Specific bug was
+ in handling of revision properties.
+ (John Arbash Meinel, Holger Krekel, #54723)
+
+* The bzr selftest was failing on installed versions due to a bug in a new
+ test helper. (John Arbash Meinel, Robert Collins, #58057)
+
+Internals
+*********
+
+* ``bzrlib.cache_utf8`` contains ``encode()`` and ``decode()`` functions
+ which can be used to cache the conversion between utf8 and Unicode.
+ Especially helpful for some of the knit annotation code, which has to
+ convert revision ids to utf8 to annotate lines in storage.
+ (John Arbash Meinel)
+
+* ``setup.py`` now searches the filesystem to find all packages which
+ need to be installed. This should help make the life of packagers
+ easier. (John Arbash Meinel)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.11.txt b/doc/en/release-notes/bzr-0.11.txt
new file mode 100644
index 0000000..6cba308
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.11.txt
@@ -0,0 +1,226 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.11
+########
+
+:Released: 2006-10-02
+
+* Smart server transport test failures on windows fixed. (Lukáš Lalinský).
+
+bzr 0.11rc2
+###########
+
+:Released: 2006-09-27
+
+Bug Fixes
+*********
+
+* Test suite hangs on windows fixed. (Andrew Bennets, Alexander Belchenko).
+
+* Commit performance regression fixed. (Aaron Bentley, Robert Collins, John
+ Arbash Meinel).
+
+bzr 0.11rc1
+###########
+
+:Released: 2006-09-25
+
+Improvements
+************
+
+* Knit files now wait to create their contents until the first data is
+ added. The old code used to create an empty .knit and a .kndx with just
+ the header. However, this caused a lot of extra round trips over SFTP.
+ This can change the time for ``bzr push`` to create a new remote branch
+ from 160s down to 100s. This also affects ``bzr commit`` performance when
+ adding new files, ``bzr commit`` on a new kernel-like tree drops from 50s
+ down to 40s (John Arbash Meinel, #44692)
+
+* When an entire subtree has been deleted, commit will now report that
+ just the top of the subtree has been deleted, rather than reporting
+ all the individual items. (Robert Collins)
+
+* Commit performs one less XML parse. (Robert Collins)
+
+* ``bzr checkout`` now operates on readonly branches as well
+ as readwrite branches. This fixes bug #39542. (Robert Collins)
+
+* ``bzr bind`` no longer synchronises history with the master branch.
+ Binding should be followed by an update or push to synchronise the
+ two branches. This is closely related to the fix for bug #39542.
+ (Robert Collins)
+
+* ``bzrlib.lazy_import.lazy_import`` function to create on-demand
+ objects. This allows all imports to stay at the global scope, but
+ modules will not actually be imported if they are not used.
+ (John Arbash Meinel)
+
+* Support ``bzr://`` and ``bzr+ssh://`` URLS to work with the new RPC-based
+ transport which will be used with the upcoming high-performance smart
+ server. The new command ``bzr serve`` will invoke bzr in server mode,
+ which processes these requests. (Andrew Bennetts, Robert Collins, Martin
+ Pool)
+
+* New command ``bzr version-info`` which can be used to get a summary
+ of the current state of the tree. This is especially useful as part
+ of a build commands. See ``doc/version_info.txt`` for more information
+ (John Arbash Meinel)
+
+Bug Fixes
+*********
+
+* ``'bzr inventory [FILE...]'`` allows restricting the file list to a
+ specific set of files. (John Arbash Meinel, #3631)
+
+* Don't abort when annotating empty files (John Arbash Meinel, #56814)
+
+* Add ``Stanza.to_unicode()`` which can be passed to another Stanza
+ when nesting stanzas. Also, add ``read_stanza_unicode`` to handle when
+ reading a nested Stanza. (John Arbash Meinel)
+
+* Transform._set_mode() needs to stat the right file.
+ (John Arbash Meinel, #56549)
+
+* Raise WeaveFormatError rather than StopIteration when trying to read
+ an empty Weave file. (John Arbash Meinel, #46871)
+
+* Don't access e.code for generic URLErrors, only HTTPErrors have .code.
+ (Vincent Ladeuil, #59835)
+
+* Handle boundary="" lines properly to allow access through a Squid proxy.
+ (John Arbash Meinel, #57723)
+
+* revert now removes newly-added directories (Aaron Bentley, #54172)
+
+* ``bzr upgrade sftp://`` shouldn't fail to upgrade v6 branches if there
+ isn't a working tree. (David Allouche, #40679)
+
+* Give nicer error messages when a user supplies an invalid --revision
+ parameter. (John Arbash Meinel, #55420)
+
+* Handle when LANG is not recognized by python. Emit a warning, but
+ just revert to using 'ascii'. (John Arbash Meinel, #35392)
+
+* Don't use ``preexec_fn`` on win32, as it is not supported by subprocess.
+ (John Arbash Meinel)
+
+* Skip specific tests when the dependencies aren't met. This includes
+ some ``setup.py`` tests when ``python-dev`` is not available, and
+ some tests that depend on paramiko. (John Arbash Meinel, Mattheiu Moy)
+
+* Fallback to Paramiko properly, if no ``ssh`` executable exists on
+ the system. (Andrew Bennetts, John Arbash Meinel)
+
+* ``Branch.bind(other_branch)`` no longer takes a write lock on the
+ other branch, and will not push or pull between the two branches.
+ API users will need to perform a push or pull or update operation if they
+ require branch synchronisation to take place. (Robert Collins, #43744)
+
+* When creating a tarball or zipfile export, export unicode names as utf-8
+ paths. This may not work perfectly on all platforms, but has the best
+ chance of working in the common case. (John Arbash Meinel, #56815)
+
+* When committing, only files that exist in working tree or basis tree
+ may be specified (Aaron Bentley, #50793)
+
+Portability
+***********
+
+* Fixes to run on Python 2.5 (Brian M. Carlson, Martin Pool, Marien Zwart)
+
+Internals
+*********
+
+* TestCaseInTempDir now creates a separate directory for HOME, rather
+ than having HOME set to the same location as the working directory.
+ (John Arbash Meinel)
+
+* ``run_bzr_subprocess()`` can take an optional ``env_changes={}`` parameter,
+ which will update os.environ inside the spawned child. It also can
+ take a ``universal_newlines=True``, which helps when checking the output
+ of the command. (John Arbash Meinel)
+
+* Refactor SFTP vendors to allow easier re-use when SSH is used.
+ (Andrew Bennetts)
+
+* ``Transport.list_dir()`` and ``Transport.iter_files_recursive()`` should always
+ return urlescaped paths. This is now tested (there were bugs in a few
+ of the transports) (Andrew Bennetts, David Allouche, John Arbash Meinel)
+
+* New utility function ``symbol_versioning.deprecation_string``. Returns the
+ formatted string for a callable, deprecation format pair. (Robert Collins)
+
+* New TestCase helper applyDeprecated. This allows you to call a callable
+ which is deprecated without it spewing to the screen, just by supplying
+ the deprecation format string issued for it. (Robert Collins)
+
+* Transport.append and Transport.put have been deprecated in favor of
+ ``.append_bytes``, ``.append_file``, ``.put_bytes``, and
+ ``.put_file``. This removes the ambiguity in what type of object the
+ functions take. ``Transport.non_atomic_put_{bytes,file}`` has also
+ been added. Which works similarly to ``Transport.append()`` except for
+ SFTP, it doesn't have a round trip when opening the file. Also, it
+ provides functionality for creating a parent directory when trying
+ to create a file, rather than raise NoSuchFile and forcing the
+ caller to repeat their request.
+ (John Arbash Meinel)
+
+* WorkingTree has a new api ``unversion`` which allow the unversioning of
+ entries by their file id. (Robert Collins)
+
+* ``WorkingTree.pending_merges`` is deprecated. Please use the
+ ``get_parent_ids`` (introduced in 0.10) method instead. (Robert Collins)
+
+* WorkingTree has a new ``lock_tree_write`` method which locks the branch for
+ read rather than write. This is appropriate for actions which only need
+ the branch data for reference rather than mutation. A new decorator
+ ``needs_tree_write_lock`` is provided in the workingtree module. Like the
+ ``needs_read_lock`` and ``needs_write_lock`` decorators this allows static
+ declaration of the locking requirements of a function to ensure that
+ a lock is taken out for casual scripts. (Robert Collins, #54107)
+
+* All WorkingTree methods which write to the tree, but not to the branch
+ have been converted to use ``needs_tree_write_lock`` rather than
+ ``needs_write_lock``. Also converted is the revert, conflicts and tree
+ transform modules. This provides a modest performance improvement on
+ metadir style trees, due to the reduce lock-acquisition, and a more
+ significant performance improvement on lightweight checkouts from
+ remote branches, where trivial operations used to pay a significant
+ penalty. It also provides the basis for allowing readonly checkouts.
+ (Robert Collins)
+
+* Special case importing the standard library 'copy' module. This shaves
+ off 40ms of startup time, while retaining compatibility. See:
+ ``bzrlib/inspect_for_copy.py`` for more details. (John Arbash Meinel)
+
+* WorkingTree has a new parent class MutableTree which represents the
+ specialisations of Tree which are able to be altered. (Robert Collins)
+
+* New methods mkdir and ``put_file_bytes_non_atomic`` on MutableTree that
+ mutate the tree and its contents. (Robert Collins)
+
+* Transport behaviour at the root of the URL is now defined and tested.
+ (Andrew Bennetts, Robert Collins)
+
+Testing
+*******
+
+* New test helper classs MemoryTree. This is typically accessed via
+ ``self.make_branch_and_memory_tree()`` in test cases. (Robert Collins)
+
+* Add ``start_bzr_subprocess`` and ``stop_bzr_subprocess`` to allow test
+ code to continue running concurrently with a subprocess of bzr.
+ (Andrew Bennetts, Robert Collins)
+
+* Add a new method ``Transport.get_smart_client()``. This is provided to
+ allow upgrades to a richer interface than the VFS one provided by
+ Transport. (Andrew Bennetts, Martin Pool)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.12.txt b/doc/en/release-notes/bzr-0.12.txt
new file mode 100644
index 0000000..3235895
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.12.txt
@@ -0,0 +1,146 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.12
+########
+
+:Released: 2006-10-30
+
+Internals
+*********
+
+* Clean up ``bzr selftest --benchmark bundle`` to correct an import,
+ and remove benchmarks that take longer than 10min to run.
+ (John Arbash Meinel)
+
+bzr 0.12rc1
+###########
+
+:Released: 2006-10-23
+
+Improvements
+************
+
+* ``bzr log`` now shows dotted-decimal revision numbers for all revisions,
+ rather than just showing a decimal revision number for revisions on the
+ mainline. These revision numbers are not yet accepted as input into bzr
+ commands such as log, diff etc. (Robert Collins)
+
+* revisions can now be specified using dotted-decimal revision numbers.
+ For instance, ``bzr diff -r 1.2.1..1.2.3``. (Robert Collins)
+
+* ``bzr help commands`` output is now shorter (Aaron Bentley)
+
+* ``bzr`` now uses lazy importing to reduce the startup time. This has
+ a moderate effect on lots of actions, especially ones that have
+ little to do. For example ``bzr rocks`` time is down to 116ms from
+ 283ms. (John Arbash Meinel)
+
+* New Registry class to provide name-to-object registry-like support,
+ for example for schemes where plugins can register new classes to
+ do certain tasks (e.g. log formatters). Also provides lazy registration
+ to allow modules to be loaded on request.
+ (John Arbash Meinel, Adeodato Simó)
+
+API Incompatability
+*******************
+
+* LogFormatter subclasses show now expect the 'revno' parameter to
+ show() to be a string rather than an int. (Robert Collins)
+
+Internals
+*********
+
+* ``TestCase.run_bzr``, ``run_bzr_captured``, and ``run_bzr_subprocess``
+ can take a ``working_dir='foo'`` parameter, which will change directory
+ for the command. (John Arbash Meinel)
+
+* ``bzrlib.lazy_regex.lazy_compile`` can be used to create a proxy
+ around a regex, which defers compilation until first use.
+ (John Arbash Meinel)
+
+* ``TestCase.run_bzr_subprocess`` defaults to supplying the
+ ``--no-plugins`` parameter to ensure test reproducability, and avoid
+ problems with system-wide installed plugins. (John Arbash Meinel)
+
+* Unique tree root ids are now supported. Newly created trees still
+ use the common root id for compatibility with bzr versions before 0.12.
+ (Aaron Bentley)
+
+* ``WorkingTree.set_root_id(None)`` is now deprecated. Please
+ pass in ``inventory.ROOT_ID`` if you want the default root id value.
+ (Robert Collins, John Arbash Meinel)
+
+* New method ``WorkingTree.flush()`` which will write the current memory
+ inventory out to disk. At the same time, ``read_working_inventory`` will
+ no longer trash the current tree inventory if it has been modified within
+ the current lock, and the tree will now ``flush()`` automatically on
+ ``unlock()``. ``WorkingTree.set_root_id()`` has been updated to take
+ advantage of this functionality. (Robert Collins, John Arbash Meinel)
+
+* ``bzrlib.tsort.merge_sorted`` now accepts ``generate_revnos``. This
+ parameter will cause it to add another column to its output, which
+ contains the dotted-decimal revno for each revision, as a tuple.
+ (Robert Collins)
+
+* ``LogFormatter.show_merge`` is deprecated in favour of
+ ``LogFormatter.show_merge_revno``. (Robert Collins)
+
+Bug Fixes
+*********
+
+* Avoid circular imports by creating a deprecated function for
+ ``bzrlib.tree.RevisionTree``. Callers should have been using
+ ``bzrlib.revisontree.RevisionTree`` anyway. (John Arbash Meinel,
+ #66349)
+
+* Don't use ``socket.MSG_WAITALL`` as it doesn't exist on all
+ platforms. (Martin Pool, #66356)
+
+* Don't require ``Content-Type`` in range responses. Assume they are a
+ single range if ``Content-Type`` does not exist.
+ (John Arbash Meinel, #62473)
+
+* bzr branch/pull no longer complain about progress bar cleanup when
+ interrupted during fetch. (Aaron Bentley, #54000)
+
+* ``WorkingTree.set_parent_trees()`` uses the trees to directly write
+ the basis inventory, rather than going through the repository. This
+ allows us to have 1 inventory read, and 2 inventory writes when
+ committing a new tree. (John Arbash Meinel)
+
+* When reverting, files that are not locally modified that do not exist
+ in the target are deleted, not just unversioned (Aaron Bentley)
+
+* When trying to acquire a lock, don't fail immediately. Instead, try
+ a few times (up to 1 hour) before timing out. Also, report why the
+ lock is unavailable (John Arbash Meinel, #43521, #49556)
+
+* Leave HttpTransportBase daughter classes decides how they
+ implement cloning. (Vincent Ladeuil, #61606)
+
+* diff3 does not indicate conflicts on clean merge. (Aaron Bentley)
+
+* If a commit fails, the commit message is stored in a file at the root of
+ the tree for later commit. (Cheuksan Edward Wang, Stefan Metzmacher,
+ #32054)
+
+Testing
+*******
+
+* New test base class TestCaseWithMemoryTransport offers memory-only
+ testing facilities: its not suitable for tests that need to mutate disk
+ state, but most tests should not need that and should be converted to
+ TestCaseWithMemoryTransport. (Robert Collins)
+
+* ``TestCase.make_branch_and_memory_tree`` now takes a format
+ option to set the BzrDir, Repository and Branch formats of the
+ created objects. (Robert Collins, John Arbash Meinel)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.13.txt b/doc/en/release-notes/bzr-0.13.txt
new file mode 100644
index 0000000..e4d0b88
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.13.txt
@@ -0,0 +1,145 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.13
+########
+
+:Released: 2006-12-05
+
+No changes from 0.13rc
+
+
+bzr 0.13rc1
+###########
+
+:Released: 2006-11-27
+
+Improvements
+************
+
+* New command ``bzr remove-tree`` allows the removal of the working
+ tree from a branch.
+ (Daniel Silverstone)
+
+* urllib uses shared keep-alive connections, so HTTP operations are substantially faster.
+ (Vincent Ladeuil, #53654)
+
+* ``bzr export`` allows an optional branch parameter, to export a bzr
+ tree from some other URL. For example:
+ ``bzr export bzr.tar.gz http://bazaar-vcs.org/bzr/bzr.dev``
+ (Daniel Silverstone)
+
+* Added ``bzr help topics`` to the bzr help system. This gives a
+ location for general information, outside of a specific command.
+ This includes updates for ``bzr help revisionspec`` the first topic
+ included. (Goffredo Baroncelli, John Arbash Meinel, #42714)
+
+* WSGI-compatible HTTP smart server. See ``doc/http_smart_server.txt``.
+ (Andrew Bennetts)
+
+* Knit files will now cache full texts only when the size of the
+ deltas is as large as the size of the fulltext. (Or after 200
+ deltas, whichever comes first). This has the most benefit on large
+ files with small changes, such as the inventory for a large project.
+ (eg For a project with 2500 files, and 7500 revisions, it changes
+ the size of inventory.knit from 11MB to 5.4MB) (John Arbash Meinel)
+
+Internals
+*********
+
+* New -D option given before the command line turns on debugging output
+ for particular areas. -Derror shows tracebacks on all errors.
+ (Martin Pool)
+
+* Clean up ``bzr selftest --benchmark bundle`` to correct an import,
+ and remove benchmarks that take longer than 10min to run.
+ (John Arbash Meinel)
+
+* Use ``time.time()`` instead of ``time.clock()`` to decide on
+ progress throttling. Because ``time.clock()`` is actually CPU time,
+ so over a high-latency connection, too many updates get throttled.
+ (John Arbash Meinel)
+
+* ``MemoryTransport.list_dir()`` would strip the first character for
+ files or directories in root directory. (John Arbash Meinel)
+
+* New method ``get_branch_reference`` on 'BzrDir' allows the detection of
+ branch references - which the smart server component needs.
+
+* New ``ChrootTransportDecorator``, accessible via the ``chroot+`` URL
+ prefix. It disallows any access to locations above a set URL. (Andrew
+ Bennetts)
+
+Bug Fixes
+*********
+
+* Now ``_KnitIndex`` properly decode revision ids when loading index data.
+ And optimize the knit index parsing code.
+ (Dmitry Vasiliev, John Arbash Meinel)
+
+* ``bzrlib/bzrdir.py`` was directly referencing ``bzrlib.workingtree``,
+ without importing it. This prevented ``bzr upgrade`` from working
+ unless a plugin already imported ``bzrlib.workingtree``
+ (John Arbash Meinel, #70716)
+
+* Suppress the traceback on invalid URLs (Vincent Ladeuil, #70803).
+
+* Give nicer error message when an HTTP server returns a 403
+ error code. (Vincent Ladeuil, #57644).
+
+* When a multi-range HTTP GET request fails, try a single
+ range one. If it fails too, forget about ranges. Remember that until
+ the death of the transport and propagates that to the clones.
+ (Vincent Ladeuil, #62276, #62029).
+
+* Handles user/passwords supplied in URL from command
+ line (for the urllib implementation). Don't request already
+ known passwords (Vincent Ladeuil, #42383, #44647, #48527)
+
+* ``_KnitIndex.add_versions()`` dictionary compresses revision ids as they
+ are added. This fixes bug where fetching remote revisions records
+ them as full references rather than integers.
+ (John Arbash Meinel, #64789)
+
+* ``bzr ignore`` strips trailing slashes in patterns.
+ Also ``bzr ignore`` rejects absolute paths. (Kent Gibson, #4559)
+
+* ``bzr ignore`` takes multiple arguments. (Cheuksan Edward Wang, #29488)
+
+* mv correctly handles paths that traverse symlinks.
+ (Aaron Bentley, #66964)
+
+* Give nicer looking error messages when failing to connect over SSH.
+ (John Arbash Meinel, #49172)
+
+* Pushing to a remote branch does not currently update the remote working
+ tree. After a remote push, ``bzr status`` and ``bzr diff`` on the remote
+ machine now show that the working tree is out of date.
+ (Cheuksan Edward Wang #48136)
+
+* Use patiencediff instead of difflib for determining deltas to insert
+ into knits. This avoids the O(N^3) behavior of difflib. Patience
+ diff should be O(N^2). (Cheuksan Edward Wang, #65714)
+
+* Running ``bzr log`` on nonexistent file gives an error instead of the
+ entire log history. (Cheuksan Edward Wang #50793)
+
+* ``bzr cat`` can look up contents of removed or renamed files. If the
+ pathname is ambiguous, i.e. the files in the old and new trees have
+ different id's, the default is the file in the new tree. The user can
+ use "--name-from-revision" to select the file in the old tree.
+ (Cheuksan Edward Wang, #30190)
+
+Testing
+*******
+
+* TestingHTTPRequestHandler really handles the Range header
+ (previously it was ignoring it and returning the whole file,).
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.14.txt b/doc/en/release-notes/bzr-0.14.txt
new file mode 100644
index 0000000..e8149d7
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.14.txt
@@ -0,0 +1,168 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.14
+########
+
+:Released: 2007-01-23
+
+Improvements
+************
+
+* ``bzr help global-options`` describes the global options. (Aaron Bentley)
+
+Bug Fixes
+*********
+
+* Skip documentation generation tests if the tools to do so are not
+ available. Fixes running selftest for installled copies of bzr.
+ (John Arbash Meinel, #80330)
+
+* Fix the code that discovers whether bzr is being run from it's
+ working tree to handle the case when it isn't but the directory
+ it is in is below a repository. (James Westby, #77306)
+
+
+bzr 0.14rc1
+###########
+
+:Released: 2007-01-16
+
+Improvements
+************
+
+* New connection: ``bzr+http://`` which supports tunnelling the smart
+ protocol over an HTTP connection. If writing is enabled on the bzr
+ server, then you can write over the HTTP connection.
+ (Andrew Bennetts, John Arbash Meinel)
+
+* Aliases now support quotation marks, so they can contain whitespace
+ (Marius Kruger)
+
+* PyCurlTransport now use a single curl object. By specifying explicitly
+ the 'Range' header, we avoid the need to use two different curl objects
+ (and two connections to the same server). (Vincent Ladeuil)
+
+* ``bzr commit`` does not prompt for a message until it is very likely to
+ succeed. (Aaron Bentley)
+
+* ``bzr conflicts`` now takes --text to list pathnames of text conflicts
+ (Aaron Bentley)
+
+* Fix ``iter_lines_added_or_present_in_versions`` to use a set instead
+ of a list while checking if a revision id was requested. Takes 10s
+ off of the ``fileids_affected_by_revision_ids`` time, which is 10s
+ of the ``bzr branch`` time. Also improve ``fileids_...`` time by
+ filtering lines with a regex rather than multiple ``str.find()``
+ calls. (saves another 300ms) (John Arbash Meinel)
+
+* Policy can be set for each configuration key. This allows keys to be
+ inherited properly across configuration entries. For example, this
+ should enable you to do::
+
+ [/home/user/project]
+ push_location = sftp://host/srv/project/
+ push_location:policy = appendpath
+
+ And then a branch like ``/home/user/project/mybranch`` should get an
+ automatic push location of ``sftp://host/srv/project/mybranch``.
+ (James Henstridge)
+
+* Added ``bzr status --short`` to make status report svn style flags
+ for each file. For example::
+
+ $ bzr status --short
+ A foo
+ A bar
+ D baz
+ ? wooley
+
+* 'bzr selftest --clean-output' allows easily clean temporary tests
+ directories without running tests. (Alexander Belchenko)
+
+* ``bzr help hidden-commands`` lists all hidden commands. (Aaron Bentley)
+
+* ``bzr merge`` now has an option ``--pull`` to fall back to pull if
+ local is fully merged into remote. (Jan Hudec)
+
+* ``bzr help formats`` describes available directory formats. (Aaron Bentley)
+
+Internals
+*********
+
+* A few tweaks directly to ``fileids_affected_by_revision_ids`` to
+ help speed up processing, as well allowing to extract unannotated
+ lines. Between the two ``fileids_affected_by_revision_ids`` is
+ improved by approx 10%. (John Arbash Meinel)
+
+* Change Revision serialization to only write out millisecond
+ resolution. Rather than expecting floating point serialization to
+ preserve more resolution than we need. (Henri Weichers, Martin Pool)
+
+* Test suite ends cleanly on Windows. (Vincent Ladeuil)
+
+* When ``encoding_type`` attribute of class Command is equal to 'exact',
+ force sys.stdout to be a binary stream on Windows, and therefore
+ keep exact line-endings (without LF -> CRLF conversion).
+ (Alexander Belchenko)
+
+* Single-letter short options are no longer globally declared. (Martin
+ Pool)
+
+* Before using detected user/terminal encoding bzr should check
+ that Python has corresponding codec. (Alexander Belchenko)
+
+* Formats for end-user selection are provided via a FormatRegistry (Aaron Bentley)
+
+Bug Fixes
+*********
+
+* ``bzr missing --verbose`` was showing adds/removals in the wrong
+ direction. (John Arbash Meinel)
+
+* ``bzr annotate`` now defaults to showing dotted revnos for merged
+ revisions. It cuts them off at a depth of 12 characters, but you can
+ supply ``--long`` to see the full number. You can also use
+ ``--show-ids`` to display the original revision ids, rather than
+ revision numbers and committer names. (John Arbash Meinel, #75637)
+
+* bzr now supports Win32 UNC path (e.g. ``\HOST\path``.
+ (Alexander Belchenko, #57869)
+
+* Win32-specific: output of cat, bundle and diff commands don't mangle
+ line-endings (Alexander Belchenko, #55276)
+
+* Replace broken fnmatch based ignore pattern matching with custom pattern
+ matcher.
+ (Kent Gibson, Jan Hudec #57637)
+
+* pycurl and urllib can detect short reads at different places. Update
+ the test suite to test more cases. Also detect HTTP error code 416
+ which was raised for that specific bug. Also enhance the urllib
+ robustness by detecting invalid ranges (and pycurl's one by detecting
+ short reads during the initial GET). (Vincent Ladeuil, #73948)
+
+* The urllib connection sharing interacts badly with urllib2
+ proxy setting (the connections didn't go thru the proxy
+ anymore). Defining a proper ProxyHandler solves the
+ problem. (Vincent Ladeuil, #74759)
+
+* Use urlutils to generate relative URLs, not osutils
+ (Aaron Bentley, #76229)
+
+* ``bzr status`` in a readonly directory should work without giving
+ lots of errors. (John Arbash Meinel, #76299)
+
+* Mention the revisionspec topic for the revision option help.
+ (Wouter van Heyst, #31663)
+
+* Allow plugins import from zip archives.
+ (Alexander Belchenko, #68124)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.15.txt b/doc/en/release-notes/bzr-0.15.txt
new file mode 100644
index 0000000..a21d212
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.15.txt
@@ -0,0 +1,391 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.15
+########
+
+:Released: 2007-04-01
+
+Bugfixes
+********
+
+* Handle incompatible repositories as a user issue when fetching.
+ (Aaron Bentley)
+
+* Don't give a recommendation to upgrade when branching or
+ checking out a branch that contains an old-format working tree.
+ (Martin Pool)
+
+bzr 0.15rc3
+###########
+
+:Released: 2007-03-26
+
+Changes
+*******
+
+* A warning is now displayed when opening working trees in older
+ formats, to encourage people to upgrade to WorkingTreeFormat4.
+ (Martin Pool)
+
+Improvements
+************
+
+* HTTP redirections are now taken into account when a branch (or a
+ bundle) is accessed for the first time. A message is issued at each
+ redirection to inform the user. In the past, HTTP redirections were
+ silently followed for each request which significantly degraded the
+ performances. The HTTP redirections are not followed anymore by
+ default, instead a RedirectRequested exception is raised. For bzrlib
+ users needing to follow HTTP redirections anyway,
+ ``bzrlib.transport.do_catching_redirections`` provide an easy transition
+ path. (vila)
+
+Internals
+*********
+
+* Added ``ReadLock.temporary_write_lock()`` to allow upgrading an OS read
+ lock to an OS write lock. Linux can do this without unlocking, Win32
+ needs to unlock in between. (John Arbash Meinel)
+
+* New parameter ``recommend_upgrade`` to ``BzrDir.open_workingtree``
+ to silence (when false) warnings about opening old formats.
+ (Martin Pool)
+
+* Fix minor performance regression with bzr-0.15 on pre-dirstate
+ trees. (We were reading the working inventory too many times).
+ (John Arbash Meinel)
+
+* Remove ``Branch.get_transaction()`` in favour of a simple cache of
+ ``revision_history``. Branch subclasses should override
+ ``_gen_revision_history`` rather than ``revision_history`` to make use of
+ this cache, and call ``_clear_revision_history_cache`` and
+ ``_cache_revision_history`` at appropriate times. (Andrew Bennetts)
+
+Bugfixes
+********
+
+* Take ``smtp_server`` from user config into account.
+ (vila, #92195)
+
+* Restore Unicode filename handling for versioned and unversioned files.
+ (John Arbash Meinel, #92608)
+
+* Don't fail during ``bzr commit`` if a file is marked removed, and
+ the containing directory is auto-removed. (John Arbash Meinel, #93681)
+
+* ``bzr status FILENAME`` failed on Windows because of an uncommon
+ errno. (``ERROR_DIRECTORY == 267 != ENOTDIR``).
+ (Wouter van Heyst, John Arbash Meinel, #90819)
+
+* ``bzr checkout source`` should create a local branch in the same
+ format as source. (John Arbash Meinel, #93854)
+
+* ``bzr commit`` with a kind change was failing to update the
+ last-changed-revision for directories. The
+ InventoryDirectory._unchanged only looked at the ``parent_id`` and name,
+ ignoring the fact that the kind could have changed, too.
+ (John Arbash Meinel, #90111)
+
+* ``bzr mv dir/subdir other`` was incorrectly updating files inside
+ the directory. So that there was a chance it would break commit,
+ etc. (John Arbash Meinel, #94037)
+
+* Correctly handles mutiple permanent HTTP redirections.
+ (vila, #88780)
+
+bzr 0.15rc2
+###########
+
+:Released: 2007-03-14
+
+Notes When Upgrading
+********************
+
+* Release 0.15rc2 of bzr changes the ``bzr init-repo`` command to
+ default to ``--trees`` instead of ``--no-trees``.
+ Existing shared repositories are not affected.
+
+Improvements
+************
+
+* New ``merge-directive`` command to generate machine- and human-readable
+ merge requests. (Aaron Bentley)
+
+* New ``submit:`` revision specifier makes it easy to diff against the
+ common ancestor with the submit location (Aaron Bentley)
+
+* Added support for Putty's SSH implementation. (Dmitry Vasiliev)
+
+* Added ``bzr status --versioned`` to report only versioned files,
+ not unknowns. (Kent Gibson)
+
+* Merge now autodetects the correct line-ending style for its conflict
+ markers. (Aaron Bentley)
+
+Internals
+*********
+
+* Refactored SSH vendor registration into SSHVendorManager class.
+ (Dmitry Vasiliev)
+
+Bugfixes
+********
+
+* New ``--numbered-dirs`` option to ``bzr selftest`` to use
+ numbered dirs for TestCaseInTempDir. This is default behavior
+ on Windows. Anyone can force named dirs on Windows
+ with ``--no-numbered-dirs``. (Alexander Belchenko)
+
+* Fix ``RevisionSpec_revid`` to handle the Unicode strings passed in
+ from the command line. (Marien Zwart, #90501)
+
+* Fix ``TreeTransform._iter_changes`` when both the source and
+ destination are missing. (Aaron Bentley, #88842)
+
+* Fix commit of merges with symlinks in dirstate trees.
+ (Marien Zwart)
+
+* Switch the ``bzr init-repo`` default from --no-trees to --trees.
+ (Wouter van Heyst, #53483)
+
+
+bzr 0.15rc1
+###########
+
+:Released: 2007-03-07
+
+Surprises
+*********
+
+* The default disk format has changed. Please run 'bzr upgrade' in your
+ working trees to upgrade. This new default is compatible for network
+ operations, but not for local operations. That is, if you have two
+ versions of bzr installed locally, after upgrading you can only use the
+ bzr 0.15 version. This new default does not enable tags or nested-trees
+ as they are incompatible with bzr versions before 0.15 over the network.
+
+* For users of bzrlib: Two major changes have been made to the working tree
+ api in bzrlib. The first is that many methods and attributes, including
+ the inventory attribute, are no longer valid for use until one of
+ ``lock_read``/``lock_write``/``lock_tree_write`` has been called,
+ and become invalid again after unlock is called. This has been done
+ to improve performance and correctness as part of the dirstate
+ development.
+ (Robert Collins, John A Meinel, Martin Pool, and others).
+
+* For users of bzrlib: The attribute 'tree.inventory' should be considered
+ readonly. Previously it was possible to directly alter this attribute, or
+ its contents, and have the tree notice this. This has been made
+ unsupported - it may work in some tree formats, but in the newer dirstate
+ format such actions will have no effect and will be ignored, or even
+ cause assertions. All operations possible can still be carried out by a
+ combination of the tree API, and the bzrlib.transform API. (Robert
+ Collins, John A Meinel, Martin Pool, and others).
+
+Improvements
+************
+
+* Support for OS Windows 98. Also .bzr.log on any windows system
+ saved in My Documents folder. (Alexander Belchenko)
+
+* ``bzr mv`` enhanced to support already moved files.
+ In the past the mv command would have failed if the source file doesn't
+ exist. In this situation ``bzr mv`` would now detect that the file has
+ already moved and update the repository accordingly, if the target file
+ does exist.
+ A new option ``--after`` has been added so that if two files already
+ exist, you could notify Bazaar that you have moved a (versioned) file
+ and replaced it with another. Thus in this case ``bzr move --after``
+ will only update the Bazaar identifier.
+ (Steffen Eichenberg, Marius Kruger)
+
+* ``ls`` now works on treeless branches and remote branches.
+ (Aaron Bentley)
+
+* ``bzr help global-options`` describes the global options.
+ (Aaron Bentley)
+
+* ``bzr pull --overwrite`` will now correctly overwrite checkouts.
+ (Robert Collins)
+
+* Files are now allowed to change kind (e.g. from file to symlink).
+ Supported by ``commit``, ``revert`` and ``status``
+ (Aaron Bentley)
+
+* ``inventory`` and ``unknowns`` hidden in favour of ``ls``
+ (Aaron Bentley)
+
+* ``bzr help checkouts`` descibes what checkouts are and some possible
+ uses of them. (James Westby, Aaron Bentley)
+
+* A new ``-d`` option to push, pull and merge overrides the default
+ directory. (Martin Pool)
+
+* Branch format 6: smaller, and potentially faster than format 5. Supports
+ ``append_history_only`` mode, where the log view and revnos do not change,
+ except by being added to. Stores policy settings in
+ ".bzr/branch/branch.conf".
+
+* ``append_only`` branches: Format 6 branches may be configured so that log
+ view and revnos are always consistent. Either create the branch using
+ "bzr init --append-revisions-only" or edit the config file as descriped
+ in docs/configuration.txt.
+
+* rebind: Format 6 branches retain the last-used bind location, so if you
+ "bzr unbind", you can "bzr bind" to bind to the previously-selected
+ bind location.
+
+* Builtin tags support, created and deleted by the ``tag`` command and
+ stored in the branch. Tags can be accessed with the revisionspec
+ ``-rtag:``, and listed with ``bzr tags``. Tags are not versioned
+ at present. Tags require a network incompatible upgrade. To perform this
+ upgrade, run ``bzr upgrade --dirstate-tags`` in your branch and
+ repositories. (Martin Pool)
+
+* The ``bzr://`` transport now has a well-known port number, 4155,
+ which it will use by default. (Andrew Bennetts, Martin Pool)
+
+* Bazaar now looks for user-installed plugins before looking for site-wide
+ plugins. (Jonathan Lange)
+
+* ``bzr resolve`` now detects and marks resolved text conflicts.
+ (Aaron Bentley)
+
+Internals
+*********
+
+* Internally revision ids and file ids are now passed around as utf-8
+ bytestrings, rather than treating them as Unicode strings. This has
+ performance benefits for Knits, since we no longer need to decode the
+ revision id for each line of content, nor for each entry in the index.
+ This will also help with the future dirstate format.
+ (John Arbash Meinel)
+
+* Reserved ids (any revision-id ending in a colon) are rejected by
+ versionedfiles, repositories, branches, and working trees
+ (Aaron Bentley)
+
+* Minor performance improvement by not creating a ProgressBar for
+ every KnitIndex we create. (about 90ms for a bzr.dev tree)
+ (John Arbash Meinel)
+
+* New easier to use Branch hooks facility. There are five initial hooks,
+ all documented in bzrlib.branch.BranchHooks.__init__ - ``'set_rh'``,
+ ``'post_push'``, ``'post_pull'``, ``'post_commit'``,
+ ``'post_uncommit'``. These hooks fire after the matching operation
+ on a branch has taken place, and were originally added for the
+ branchrss plugin. (Robert Collins)
+
+* New method ``Branch.push()`` which should be used when pushing from a
+ branch as it makes performance and policy decisions to match the UI
+ level command ``push``. (Robert Collins).
+
+* Add a new method ``Tree.revision_tree`` which allows access to cached
+ trees for arbitrary revisions. This allows the in development dirstate
+ tree format to provide access to the callers to cached copies of
+ inventory data which are cheaper to access than inventories from the
+ repository.
+ (Robert Collins, Martin Pool)
+
+* New ``Branch.last_revision_info`` method, this is being done to allow
+ optimization of requests for both the number of revisions and the last
+ revision of a branch with smartservers and potentially future branch
+ formats. (Wouter van Heyst, Robert Collins)
+
+* Allow ``'import bzrlib.plugins.NAME'`` to work when the plugin NAME has not
+ yet been loaded by ``load_plugins()``. This allows plugins to depend on each
+ other for code reuse without requiring users to perform file-renaming
+ gymnastics. (Robert Collins)
+
+* New Repository method ``'gather_stats'`` for statistic data collection.
+ This is expected to grow to cover a number of related uses mainly
+ related to bzr info. (Robert Collins)
+
+* Log formatters are now managed with a registry.
+ ``log.register_formatter`` continues to work, but callers accessing
+ the FORMATTERS dictionary directly will not.
+
+* Allow a start message to be passed to the ``edit_commit_message``
+ function. This will be placed in the message offered to the user
+ for editing above the separator. It allows a template commit message
+ to be used more easily. (James Westby)
+
+* ``GPGStrategy.sign()`` will now raise ``BzrBadParameterUnicode`` if
+ you pass a Unicode string rather than an 8-bit string. Callers need
+ to be updated to encode first. (John Arbash Meinel)
+
+* Branch.push, pull, merge now return Result objects with information
+ about what happened, rather than a scattering of various methods. These
+ are also passed to the post hooks. (Martin Pool)
+
+* File formats and architecture is in place for managing a forest of trees
+ in bzr, and splitting up existing trees into smaller subtrees, and
+ finally joining trees to make a larger tree. This is the first iteration
+ of this support, and the user-facing aspects still require substantial
+ work. If you wish to experiment with it, use ``bzr upgrade
+ --dirstate-with-subtree`` in your working trees and repositories.
+ You can use the hidden commands ``split`` and ``join`` and to create
+ and manipulate nested trees, but please consider using the nested-trees
+ branch, which contains substantial UI improvements, instead.
+ http://code.aaronbentley.com/bzr/bzrrepo/nested-trees/
+ (Aaron Bentley, Martin Pool, Robert Collins).
+
+Bugfixes
+********
+
+* ``bzr annotate`` now uses dotted revnos from the viewpoint of the
+ branch, rather than the last changed revision of the file.
+ (John Arbash Meinel, #82158)
+
+* Lock operations no longer hang if they encounter a permission problem.
+ (Aaron Bentley)
+
+* ``bzr push`` can resume a push that was canceled before it finished.
+ Also, it can push even if the target directory exists if you supply
+ the ``--use-existing-dir`` flag.
+ (John Arbash Meinel, #30576, #45504)
+
+* Fix HTTP proxy authentication when user and an optional
+ password appears in the ``*_proxy`` vars. (Vincent Ladeuil,
+ #83954).
+
+* ``bzr log branch/file`` works for local treeless branches
+ (Aaron Bentley, #84247)
+
+* Fix problem with UNC paths on Windows 98. (Alexander Belchenko, #84728)
+
+* Searching location of CA bundle for PyCurl in env variable
+ (``CURL_CA_BUNDLE``), and on win32 along the PATH.
+ (Alexander Belchenko, #82086)
+
+* ``bzr init`` works with unicode argument LOCATION.
+ (Alexander Belchenko, #85599)
+
+* Raise ``DependencyNotPresent`` if pycurl do not support https.
+ (Vincent Ladeuil, #85305)
+
+* Invalid proxy env variables should not cause a traceback.
+ (Vincent Ladeuil, #87765)
+
+* Ignore patterns normalised to use '/' path separator.
+ (Kent Gibson, #86451)
+
+* bzr rocks. It sure does! Fix case. (Vincent Ladeuil, #78026)
+
+* Fix bzrtools shelve command for removed lines beginning with "--"
+ (Johan Dahlberg, #75577)
+
+Testing
+*******
+
+* New ``--first`` option to ``bzr selftest`` to run specified tests
+ before the rest of the suite. (Martin Pool)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.16.txt b/doc/en/release-notes/bzr-0.16.txt
new file mode 100644
index 0000000..ef469bd
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.16.txt
@@ -0,0 +1,379 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.16
+########
+
+:Released: 2007-05-07
+
+Bugfixes
+********
+
+* Handle when you have 2 directories with similar names, but one has a
+ hyphen. (``'abc'`` versus ``'abc-2'``). The WT4._iter_changes
+ iterator was using direct comparison and ``'abc/a'`` sorts after
+ ``'abc-2'``, but ``('abc', 'a')`` sorts before ``('abc-2',)``.
+ (John Arbash Meinel, #111127)
+
+* Handle when someone renames a file on disk without telling bzr.
+ Previously we would report the first file as missing, but not show
+ the new unknown file. (John Arbash Meinel, #111288)
+
+* Avoid error when running hooks after pulling into or pushing from
+ a branch bound to a smartserver branch. (Martin Pool, #111968)
+
+Improvements
+************
+
+* Move developer documentation to doc/developers/. This reduces clutter in
+ the root of the source tree and allows HACKING to be split into multiple
+ files. (Robert Collins, Alexander Belchenko)
+
+* Clean up the ``WorkingTree4._iter_changes()`` internal loops as well as
+ ``DirState.update_entry()``. This optimizes the core logic for ``bzr
+ diff`` and ``bzr status`` significantly improving the speed of
+ both. (John Arbash Meinel)
+
+bzr 0.16rc2
+###########
+
+:Released: 2007-04-30
+
+Bugfixes
+********
+
+* Handle the case when you delete a file, and then rename another file
+ on top of it. Also handle the case of ``bzr rm --keep foo``. ``bzr
+ status`` should show the removed file and an unknown file in its
+ place. (John Arbash Meinel, #109993)
+
+* Bundles properly read and write revision properties that have an
+ empty value. And when the value is not ASCII.
+ (John Arbash Meinel, #109613)
+
+* Fix the bzr commit message to be in text mode.
+ (Alexander Belchenko, #110901)
+
+* Also handle when you rename a file and create a file where it used
+ to be. (John Arbash Meinel, #110256)
+
+* ``WorkingTree4._iter_changes`` should not descend into unversioned
+ directories. (John Arbash Meinel, #110399)
+
+bzr 0.16rc1
+###########
+
+:Released: 2007-04-26
+
+Notes When Upgrading
+********************
+
+* ``bzr remove`` and ``bzr rm`` will now remove the working file, if
+ it could be recovered again.
+ This has been done for consistency with svn and the unix rm command.
+ The old ``remove`` behaviour has been retained in the new option
+ ``bzr remove --keep``, which will just stop versioning the file,
+ but not delete it.
+ ``bzr remove --force`` have been added which will always delete the
+ files.
+ ``bzr remove`` is also more verbose.
+ (Marius Kruger, #82602)
+
+Improvements
+************
+
+* Merge directives can now be supplied as input to `merge` and `pull`,
+ like bundles can. (Aaron Bentley)
+
+* Sending the SIGQUIT signal to bzr, which can be done on Unix by
+ pressing Control-Backslash, drops bzr into a debugger. Type ``'c'``
+ to continue. This can be disabled by setting the environment variable
+ ``BZR_SIGQUIT_PDB=0``. (Martin Pool)
+
+* selftest now supports --list-only to list tests instead of running
+ them. (Ian Clatworthy)
+
+* selftest now supports --exclude PATTERN (or -x PATTERN) to exclude
+ tests with names that match that regular expression.
+ (Ian Clatworthy, #102679)
+
+* selftest now supports --randomize SEED to run tests in a random order.
+ SEED is typically the value 'now' meaning 'use the current time'.
+ (Ian Clatworthy, #102686)
+
+* New option ``--fixes`` to commit, which stores bug fixing annotations as
+ revision properties. Built-in support for Launchpad, Debian, Trac and
+ Bugzilla bug trackers. (Jonathan Lange, James Henstridge, Robert Collins)
+
+* New API, ``bzrlib.bugtracker.tracker_registry``, for adding support for
+ other bug trackers to ``fixes``. (Jonathan Lange, James Henstridge,
+ Robert Collins)
+
+* ``selftest`` has new short options ``-f`` and ``-1``. (Martin
+ Pool)
+
+* ``bzrlib.tsort.MergeSorter`` optimizations. Change the inner loop
+ into using local variables instead of going through ``self._var``.
+ Improves the time to ``merge_sort`` a 10k revision graph by
+ approximately 40% (~700->400ms). (John Arbash Meinel)
+
+* ``make docs`` now creates a man page at ``man1/bzr.1`` fixing bug 107388.
+ (Robert Collins)
+
+* ``bzr help`` now provides cross references to other help topics using
+ the _see_also facility on command classes. Likewise the bzr_man
+ documentation, and the bzr.1 man page also include this information.
+ (Robert Collins)
+
+* Tags are now included in logs, that use the long log formatter.
+ (Erik Bågfors, Alexander Belchenko)
+
+* ``bzr help`` provides a clearer message when a help topic cannot be
+ found. (Robert Collins, #107656)
+
+* ``bzr help`` now accepts optional prefixes for command help. The help
+ for all commands can now be found at ``bzr help commands/COMMANDNAME``
+ as well as ``bzr help COMMANDNAME`` (which only works for commands
+ where the name is not the same as a more general help topic).
+ (Robert Collins)
+
+* ``bzr help PLUGINNAME`` will now return the module docstring from the
+ plugin PLUGINNAME. (Robert Collins, #50408)
+
+* New help topic ``urlspec`` which lists the availables transports.
+ (Goffredo Baroncelli)
+
+* doc/server.txt updated to document the default bzr:// port
+ and also update the blurb about the hpss' current status.
+ (Robert Collins, #107125).
+
+* ``bzr serve`` now listens on interface 0.0.0.0 by default, making it
+ serve out to the local LAN (and anyone in the world that can reach the
+ machine running ``bzr serve``. (Robert Collins, #98918)
+
+* A new smart server protocol version has been added. It prefixes requests
+ and responses with an explicit version identifier so that future protocol
+ revisions can be dealt with gracefully. (Andrew Bennetts, Robert Collins)
+
+* The bzr protocol version 2 indicates success or failure in every response
+ without depending on particular commands encoding that consistently,
+ allowing future client refactorings to be much more robust about error
+ handling. (Robert Collins, Martin Pool, Andrew Bennetts)
+
+* The smart protocol over HTTP client has been changed to always post to the
+ same ``.bzr/smart`` URL under the original location when it can. This allows
+ HTTP servers to only have to pass URLs ending in .bzr/smart to the smart
+ server handler, and not arbitrary ``.bzr/*/smart`` URLs. (Andrew Bennetts)
+
+* digest authentication is now supported for proxies and HTTP by the urllib
+ based HTTP implementation. Tested against Apache 2.0.55 and Squid
+ 2.6.5. Basic and digest authentication are handled coherently for HTTP
+ and proxy: if the user is provided in the URL (bzr command line for HTTP,
+ proxy environment variables for proxies), the password is prompted for
+ (only once). If the password is provided, it is taken into account. Once
+ the first authentication is successful, all further authentication
+ roundtrips are avoided by preventively setting the right authentication
+ header(s).
+ (Vincent Ladeuil).
+
+Internals
+*********
+
+* bzrlib API compatability with 0.8 has been dropped, cleaning up some
+ code paths. (Robert Collins)
+
+* Change the format of chroot URLS so that they can be safely manipulated
+ by generic URL utilities without causing the resulting URLs to have
+ escaped the chroot. A side effect of this is that creating a chroot
+ requires an explicit action using a ChrootServer.
+ (Robert Collins, Andrew Bennetts)
+
+* Deprecate ``Branch.get_root_id()`` because branches don't have root ids,
+ rather than fixing bug #96847. (Aaron Bentley)
+
+* ``WorkingTree.apply_inventory_delta`` provides a better alternative to
+ ``WorkingTree._write_inventory``. (Aaron Bentley)
+
+* Convenience method ``TestCase.expectFailure`` ensures that known failures
+ do not silently pass. (Aaron Bentley)
+
+* ``Transport.local_abspath`` now raises ``NotLocalUrl`` rather than
+ ``TransportNotPossible``. (Martin Pool, Ian Clatworthy)
+
+* New SmartServer hooks facility. There are two initial hooks documented
+ in ``bzrlib.transport.smart.SmartServerHooks``. The two initial hooks allow
+ plugins to execute code upon server startup and shutdown.
+ (Robert Collins).
+
+* SmartServer in standalone mode will now close its listening socket
+ when it stops, rather than waiting for garbage collection. This primarily
+ fixes test suite hangs when a test tries to connect to a shutdown server.
+ It may also help improve behaviour when dealing with a server running
+ on a specific port (rather than dynamically assigned ports).
+ (Robert Collins)
+
+* Move most SmartServer code into a new package, bzrlib/smart.
+ bzrlib/transport/remote.py contains just the Transport classes that used
+ to be in bzrlib/transport/smart.py. (Andrew Bennetts)
+
+* urllib HTTP implementation avoid roundtrips associated with
+ 401 (and 407) errors once the authentication succeeds.
+ (Vincent Ladeuil).
+
+* urlib HTTP now supports querying the user for a proxy password if
+ needed. Realm is shown in the prompt for both HTTP and proxy
+ authentication when the user is required to type a password.
+ (Vincent Ladeuil).
+
+* Renamed SmartTransport (and subclasses like SmartTCPTransport) to
+ RemoteTransport (and subclasses to RemoteTCPTransport, etc). This is more
+ consistent with its new home in ``bzrlib/transport/remote.py``, and because
+ it's not really a "smart" transport, just one that does file operations
+ via remote procedure calls. (Andrew Bennetts)
+
+* The ``lock_write`` method of ``LockableFiles``, ``Repository`` and
+ ``Branch`` now accept a ``token`` keyword argument, so that separate
+ instances of those objects can share a lock if it has the right token.
+ (Andrew Bennetts, Robert Collins)
+
+* New method ``get_branch_reference`` on ``BzrDir`` allows the detection of
+ branch references - which the smart server component needs.
+
+* The Repository API ``make_working_trees`` is now permitted to return
+ False when ``set_make_working_trees`` is not implemented - previously
+ an unimplemented ``set_make_working_trees`` implied the result True
+ from ``make_working_trees``. This has been changed to accomodate the
+ smart server, where it does not make sense (at this point) to ever
+ make working trees by default. (Robert Collins)
+
+* Command objects can now declare related help topics by having _see_also
+ set to a list of related topic. (Robert Collins)
+
+* ``bzrlib.help`` now delegates to the Command class for Command specific
+ help. (Robert Collins)
+
+* New class ``TransportListRegistry``, derived from the Registry class, which
+ simplifies tracking the available Transports. (Goffredo Baroncelli)
+
+* New function ``Branch.get_revision_id_to_revno_map`` which will
+ return a dictionary mapping revision ids to dotted revnos. Since
+ dotted revnos are defined in the context of the branch tip, it makes
+ sense to generate them from a ``Branch`` object.
+ (John Arbash Meinel)
+
+* Fix the 'Unprintable error' message display to use the repr of the
+ exception that prevented printing the error because the str value
+ for it is often not useful in debugging (e.g. KeyError('foo') has a
+ str() of 'foo' but a repr of 'KeyError('foo')' which is much more
+ useful. (Robert Collins)
+
+* ``urlutils.normalize_url`` now unescapes unreserved characters, such as "~".
+ (Andrew Bennetts)
+
+Bugfixes
+********
+
+* Don't fail bundle selftest if email has 'two' embedded.
+ (Ian Clatworthy, #98510)
+
+* Remove ``--verbose`` from ``bzr bundle``. It didn't work anyway.
+ (Robert Widhopf-Fenk, #98591)
+
+* Remove ``--basis`` from the checkout/branch commands - it didn't work
+ properly and is no longer beneficial.
+ (Robert Collins, #53675, #43486)
+
+* Don't produce encoding error when adding duplicate files.
+ (Aaron Bentley)
+
+* Fix ``bzr log <file>`` so it only logs the revisions that changed
+ the file, and does it faster.
+ (Kent Gibson, John Arbash Meinel, #51980, #69477)
+
+* Fix ``InterDirstateTre._iter_changes`` to handle when we come across
+ an empty versioned directory, which now has files in it.
+ (John Arbash Meinel, #104257)
+
+* Teach ``common_ancestor`` to shortcut when the tip of one branch is
+ inside the ancestry of the other. Saves a lot of graph processing
+ (with an ancestry of 16k revisions, ``bzr merge ../already-merged``
+ changes from 2m10s to 13s). (John Arbash Meinel, #103757)
+
+* Fix ``show_diff_trees`` to handle the case when a file is modified,
+ and the containing directory is renamed. (The file path is different
+ in this versus base, but it isn't marked as a rename).
+ (John Arbash Meinel, #103870)
+
+* FTP now works even when the FTP server does not support atomic rename.
+ (Aaron Bentley, #89436)
+
+* Correct handling in bundles and merge directives of timezones with
+ that are not an integer number of hours offset from UTC. Always
+ represent the epoch time in UTC to avoid problems with formatting
+ earlier times on win32. (Martin Pool, Alexander Belchenko, John
+ Arbash Meinel)
+
+* Typo in the help for ``register-branch`` fixed. (Robert Collins, #96770)
+
+* "dirstate" and "dirstate-tags" formats now produce branches compatible
+ with old versions of bzr. (Aaron Bentley, #107168))
+
+* Handle moving a directory when children have been added, removed,
+ and renamed. (John Arbash Meinel, #105479)
+
+* Don't preventively use basic authentication for proxy before receiving a
+ 407 error. Otherwise people willing to use other authentication schemes
+ may expose their password in the clear (or nearly). This add one
+ roundtrip in case basic authentication should be used, but plug the
+ security hole.
+ (Vincent Ladeuil)
+
+* Handle HTTP and proxy digest authentication.
+ (Vincent Ladeuil, #94034).
+
+Testing
+*******
+
+* Added ``bzrlib.strace.strace`` which will strace a single callable and
+ return a StraceResult object which contains just the syscalls involved
+ in running it. (Robert Collins)
+
+* New test method ``reduceLockdirTimeout`` to drop the default (ui-centric)
+ default time down to one suitable for tests. (Andrew Bennetts)
+
+* Add new ``vfs_transport_factory`` attribute on tests which provides the
+ common vfs backing for both the readonly and readwrite transports.
+ This allows the RemoteObject tests to back onto local disk or memory,
+ and use the existing ``transport_server`` attribute all tests know about
+ to be the smart server transport. This in turn allows tests to
+ differentiate between 'transport to access the branch', and
+ 'transport which is a VFS' - which matters in Remote* tests.
+ (Robert Collins, Andrew Bennetts)
+
+* The ``make_branch_and_tree`` method for tests will now create a
+ lightweight checkout for the tree if the ``vfs_transport_factory`` is not
+ a LocalURLServer. (Robert Collins, Andrew Bennetts)
+
+* Branch implementation tests have been audited to ensure that all URLs
+ passed to Branch APIs use proper URLs, except when local-disk paths
+ are intended. This is so that tests correctly access the test transport
+ which is often not equivalent to local disk in Remote* tests. As part
+ of this many tests were adjusted to remove dependencies on local disk
+ access.
+ (Robert Collins, Andrew Bennetts)
+
+* Mark bzrlib.tests and bzrlib.tests.TestUtil as providing assertFOO helper
+ functions by adding a ``__unittest`` global attribute. (Robert Collins,
+ Andrew Bennetts, Martin Pool, Jonathan Lange)
+
+* Refactored proxy and authentication handling to simplify the
+ implementation of new auth schemes for both HTTP and proxy.
+ (Vincent Ladeuil)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.17.txt b/doc/en/release-notes/bzr-0.17.txt
new file mode 100644
index 0000000..34fa998
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.17.txt
@@ -0,0 +1,129 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.17
+########
+
+:Released: 2007-06-18
+
+Bugfixes
+********
+
+* Fix crash of commit due to wrong lookup of filesystem encoding.
+ (Colin Watson, #120647)
+
+* Revert logging just to stderr in commit as broke unicode filenames.
+ (Aaron Bentley, Ian Clatworthy, #120930)
+
+
+bzr 0.17rc1
+###########
+
+:Released: 2007-06-12
+
+Notes When Upgrading
+********************
+
+* The kind() and is_executable() APIs on the WorkingTree interface no
+ longer implicitly (read) locks and unlocks the tree. This *might*
+ impact some plug-ins and tools using this part of the API. If you find
+ an issue that may be caused by this change, please let us know,
+ particularly the plug-in/tool maintainer. If encountered, the API
+ fix is to surround kind() and is_executable() calls with lock_read()
+ and unlock() like so::
+
+ work_tree.lock_read()
+ try:
+ kind = work_tree.kind(...)
+ finally:
+ work_tree.unlock()
+
+Internals
+*********
+* Rework of LogFormatter API to provide beginning/end of log hooks and to
+ encapsulate the details of the revision to be logged in a LogRevision
+ object.
+ In long log formats, merge revision ids are only shown when --show-ids
+ is specified, and are labelled "revision-id:", as per mainline
+ revisions, instead of "merged:". (Kent Gibson)
+
+* New ``BranchBuilder`` API which allows the construction of particular
+ histories quickly. Useful for testing and potentially other applications
+ too. (Robert Collins)
+
+Improvements
+************
+
+* There are two new help topics, working-trees and repositories that
+ attempt to explain these concepts. (James Westby, John Arbash Meinel,
+ Aaron Bentley)
+
+* Added ``bzr log --limit`` to report a limited number of revisions.
+ (Kent Gibson, #3659)
+
+* Revert does not try to preserve file contents that were originally
+ produced by reverting to a historical revision. (Aaron Bentley)
+
+* ``bzr log --short`` now includes ``[merge]`` for revisions which
+ have more than one parent. This is a small improvement to help
+ understanding what changes have occurred
+ (John Arbash Meinel, #83887)
+
+* TreeTransform avoids many renames when contructing large trees,
+ improving speed. 3.25x speedups have been observed for construction of
+ kernel-sized-trees, and checkouts are 1.28x faster. (Aaron Bentley)
+
+* Commit on large trees is now faster. In my environment, a commit of
+ a small change to the Mozilla tree (55k files) has dropped from
+ 66 seconds to 32 seconds. For a small tree of 600 files, commit of a
+ small change is 33% faster. (Ian Clatworthy)
+
+* New --create-prefix option to bzr init, like for push. (Daniel Watkins,
+ #56322)
+
+Bugfixes
+********
+
+* ``bzr push`` should only connect to the remote location one time.
+ We have been connecting 3 times because we forget to pass around
+ the Transport object. This adds ``BzrDir.clone_on_transport()``, so
+ that we can pass in the Transport that we already have.
+ (John Arbash Meinel, #75721)
+
+* ``DirState.set_state_from_inventory()`` needs to properly order
+ based on split paths, not just string paths.
+ (John Arbash Meinel, #115947)
+
+* Let TestUIFactoy encode the password prompt with its own stdout.
+ (Vincent Ladeuil, #110204)
+
+* pycurl should take use the range header that takes the range hint
+ into account.
+ (Vincent Ladeuil, #112719)
+
+* WorkingTree4.get_file_sha1 no longer raises an exception when invoked
+ on a missing file. (Aaron Bentley, #118186)
+
+* WorkingTree.remove works correctly with tree references, and when pwd is
+ not the tree root. (Aaron Bentley)
+
+* Merge no longer fails when a file is renamed in one tree and deleted
+ in the other. (Aaron Bentley, #110279)
+
+* ``revision-info`` now accepts dotted revnos, doesn't require a tree,
+ and defaults to the last revision (Matthew Fuller, #90048)
+
+* Tests no longer fail when BZR_REMOTE_PATH is set in the environment.
+ (Daniel Watkins, #111958)
+
+* ``bzr branch -r revid:foo`` can be used to branch any revision in
+ your repository. (Previously Branch6 only supported revisions in your
+ mainline). (John Arbash Meinel, #115343)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.18.txt b/doc/en/release-notes/bzr-0.18.txt
new file mode 100644
index 0000000..1470c05
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.18.txt
@@ -0,0 +1,274 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.18
+########
+
+:Released: 2007-07-17
+
+Bugfixes
+********
+
+* Fix 'bzr add' crash under Win32 (Kuno Meyer)
+
+
+bzr 0.18rc1
+###########
+
+:Released: 2007-07-10
+
+Bugfixes
+********
+
+* Do not suppress pipe errors, etc. in non-display commands
+ (Alexander Belchenko, #87178)
+
+* Display a useful error message when the user requests to annotate
+ a file that is not present in the specified revision.
+ (James Westby, #122656)
+
+* Commands that use status flags now have a reference to 'help
+ status-flags'. (Daniel Watkins, #113436)
+
+* Work around python-2.4.1 inhability to correctly parse the
+ authentication header.
+ (Vincent Ladeuil, #121889)
+
+* Use exact encoding for merge directives. (Adeodato Simó, #120591)
+
+* Fix tempfile permissions error in smart server tar bundling under
+ Windows. (Martin _, #119330)
+
+* Fix detection of directory entries in the inventory. (James Westby)
+
+* Fix handling of HTTP code 400: Bad Request When issuing too many ranges.
+ (Vincent Ladeuil, #115209)
+
+* Issue a CONNECT request when connecting to an https server
+ via a proxy to enable SSL tunneling.
+ (Vincent Ladeuil, #120678)
+
+* Fix ``bzr log -r`` to support selecting merge revisions, both
+ individually and as part of revision ranges.
+ (Kent Gibson, #4663)
+
+* Don't leave cruft behind when failing to acquire a lockdir.
+ (Martin Pool, #109169)
+
+* Don't use the '-f' strace option during tests.
+ (Vincent Ladeuil, #102019).
+
+* Warn when setting ``push_location`` to a value that will be masked by
+ locations.conf. (Aaron Bentley, #122286)
+
+* Fix commit ordering in corner case (Aaron Bentley, #94975)
+
+* Make annotate behave in a non-ASCII world (Adeodato Simó).
+
+Improvements
+************
+
+* The --lsprof-file option now dumps a text rendering of the profiling
+ information if the filename ends in ".txt". It will also convert the
+ profiling information to a format suitable for KCacheGrind if the
+ output filename ends in ".callgrind". Fixes to the lsprofcalltree
+ conversion process by Jean Paul Calderone and Itamar were also merged.
+ See http://ddaa.net/blog/python/lsprof-calltree. (Ian Clatworthy)
+
+* ``info`` now defaults to non-verbose mode, displaying only paths and
+ abbreviated format info. ``info -v`` displays all the information
+ formerly displayed by ``info``. (Aaron Bentley, Adeodato Simó)
+
+* ``bzr missing`` now has better option names ``--this`` and ``--other``.
+ (Elliot Murphy)
+
+* The internal ``weave-list`` command has become ``versionedfile-list``,
+ and now lists knits as well as weaves. (Aaron Bentley)
+
+* Automatic merge base selection uses a faster algorithm that chooses
+ better bases in criss-cross merge situations (Aaron Bentley)
+
+* Progress reporting in ``commit`` has been improved. The various logical
+ stages are now reported on as follows, namely:
+
+ * Collecting changes [Entry x/y] - Stage n/m
+ * Saving data locally - Stage n/m
+ * Uploading data to master branch - Stage n/m
+ * Updating the working tree - Stage n/m
+ * Running post commit hooks - Stage n/m
+
+ If there is no master branch, the 3rd stage is omitted and the total
+ number of stages is adjusted accordingly.
+
+ Each hook that is run after commit is listed with a name (as hooks
+ can be slow it is useful feedback).
+ (Ian Clatworthy, Robert Collins)
+
+* Various operations that are now faster due to avoiding unnecessary
+ topological sorts. (Aaron Bentley)
+
+* Make merge directives robust against broken bundles. (Aaron Bentley)
+
+* The lsprof filename note is emitted via trace.note(), not standard
+ output. (Aaron Bentley)
+
+* ``bzrlib`` now exports explicit API compatibility information to assist
+ library users and plugins. See the ``bzrlib.api`` module for details.
+ (Robert Collins)
+
+* Remove unnecessary lock probes when acquiring a lockdir.
+ (Martin Pool)
+
+* ``bzr --version`` now shows the location of the bzr log file, which
+ is especially useful on Windows. (Martin Pool)
+
+* -D now supports hooks to get debug tracing of hooks (though its currently
+ minimal in nature). (Robert Collins)
+
+* Long log format reports deltas on merge revisions.
+ (John Arbash Meinel, Kent Gibson)
+
+* Make initial push over FTP more resilient. (John Arbash Meinel)
+
+* Print a summary of changes for update just like pull does.
+ (Daniel Watkins, #113990)
+
+* Add a -Dhpss option to trace smart protocol requests and responses.
+ (Andrew Bennetts)
+
+Library API Breaks
+******************
+
+* Testing cleanups -
+ ``bzrlib.repository.RepositoryTestProviderAdapter`` has been moved
+ to ``bzrlib.tests.repository_implementations``;
+ ``bzrlib.repository.InterRepositoryTestProviderAdapter`` has been moved
+ to ``bzrlib.tests.interrepository_implementations``;
+ ``bzrlib.transport.TransportTestProviderAdapter`` has moved to
+ ``bzrlib.tests.test_transport_implementations``.
+ ``bzrlib.branch.BranchTestProviderAdapter`` has moved to
+ ``bzrlib.tests.branch_implementations``.
+ ``bzrlib.bzrdir.BzrDirTestProviderAdapter`` has moved to
+ ``bzrlib.tests.bzrdir_implementations``.
+ ``bzrlib.versionedfile.InterVersionedFileTestProviderAdapter`` has moved
+ to ``bzrlib.tests.interversionedfile_implementations``.
+ ``bzrlib.store.revision.RevisionStoreTestProviderAdapter`` has moved to
+ ``bzrlib.tests.revisionstore_implementations``.
+ ``bzrlib.workingtree.WorkingTreeTestProviderAdapter`` has moved to
+ ``bzrlib.tests.workingtree_implementations``.
+ These changes are an API break in the testing infrastructure only.
+ (Robert Collins)
+
+* Relocate TestCaseWithRepository to be more central. (Robert Collins)
+
+* ``bzrlib.add.smart_add_tree`` will no longer perform glob expansion on
+ win32. Callers of the function should do this and use the new
+ ``MutableTree.smart_add`` method instead. (Robert Collins)
+
+* ``bzrlib.add.glob_expand_for_win32`` is now
+ ``bzrlib.win32utils.glob_expand``. (Robert Collins)
+
+* ``bzrlib.add.FastPath`` is now private and moved to
+ ``bzrlib.mutabletree._FastPath``. (Robert Collins, Martin Pool)
+
+* ``LockDir.wait`` removed. (Martin Pool)
+
+* The ``SmartServer`` hooks API has changed for the ``server_started`` and
+ ``server_stopped`` hooks. The first parameter is now an iterable of
+ backing URLs rather than a single URL. This is to reflect that many
+ URLs may map to the external URL of the server. E.g. the server interally
+ may have a chrooted URL but also the local file:// URL will be at the
+ same location. (Robert Collins)
+
+Internals
+*********
+
+* New SMTPConnection class to unify email handling. (Adeodato Simó)
+
+* Fix documentation of BzrError. (Adeodato Simó)
+
+* Make BzrBadParameter an internal error. (Adeodato Simó)
+
+* Remove use of 'assert False' to raise an exception unconditionally.
+ (Martin Pool)
+
+* Give a cleaner error when failing to decode knit index entry.
+ (Martin Pool)
+
+* TreeConfig would mistakenly search the top level when asked for options
+ from a section. It now respects the section argument and only
+ searches the specified section. (James Westby)
+
+* Improve ``make api-docs`` output. (John Arbash Meinel)
+
+* Use os.lstat rather than os.stat for osutils.make_readonly and
+ osutils.make_writeable. This makes the difftools plugin more
+ robust when dangling symlinks are found. (Elliot Murphy)
+
+* New ``-Dlock`` option to log (to ~/.bzr.log) information on when
+ lockdirs are taken or released. (Martin Pool)
+
+* ``bzrlib`` Hooks are now nameable using ``Hooks.name_hook``. This
+ allows a nicer UI when hooks are running as the current hook can
+ be displayed. (Robert Collins)
+
+* ``Transport.get`` has had its interface made more clear for ease of use.
+ Retrieval of a directory must now fail with either 'PathError' at open
+ time, or raise 'ReadError' on a read. (Robert Collins)
+
+* New method ``_maybe_expand_globs`` on the ``Command`` class for
+ dealing with unexpanded glob lists - e.g. on the win32 platform. This
+ was moved from ``bzrlib.add._prepare_file_list``. (Robert Collins)
+
+* ``bzrlib.add.smart_add`` and ``bzrlib.add.smart_add_tree`` are now
+ deprecated in favour of ``MutableTree.smart_add``. (Robert Collins,
+ Martin Pool)
+
+* New method ``external_url`` on Transport for obtaining the URL to
+ hand to external processes. (Robert Collins)
+
+* Teach windows installers to build pyrex/C extensions.
+ (Alexander Belchenko)
+
+Testing
+*******
+
+* Removed the ``--keep-output`` option from selftest and clean up test
+ directories as they're used. This reduces the IO load from
+ running the test suite and cuts the time by about half.
+ (Andrew Bennetts, Martin Pool)
+
+* Add scenarios as a public attribute on the TestAdapter classes to allow
+ modification of the generated scenarios before adaption and easier
+ testing. (Robert Collins)
+
+* New testing support class ``TestScenarioApplier`` which multiplies
+ out a single teste by a list of supplied scenarios. (RobertCollins)
+
+* Setting ``repository_to_test_repository`` on a repository_implementations
+ test will cause it to be called during repository creation, allowing the
+ testing of repository classes which are not based around the Format
+ concept. For example a repository adapter can be tested in this manner,
+ by altering the repository scenarios to include a scenario that sets this
+ attribute during the test parameterisation in
+ ``bzrlib.tests.repository.repository_implementations``. (Robert Collins)
+
+* Clean up many of the APIs for blackbox testing of Bazaar. The standard
+ interface is now self.run_bzr. The command to run can be passed as
+ either a list of parameters, a string containing the command line, or
+ (deprecated) varargs parameters. (Martin Pool)
+
+* The base TestCase now isolates tests from -D parameters by clearing
+ ``debug.debug_flags`` and restores it afterwards. (Robert Collins)
+
+* Add a relpath parameter to get_transport methods in test framework to
+ avoid useless cloning.
+ (Vincent Ladeuil, #110448)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.6.txt b/doc/en/release-notes/bzr-0.6.txt
new file mode 100644
index 0000000..372b70f
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.6.txt
@@ -0,0 +1,227 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.6
+#######
+
+:Released: 2005-10-28
+
+Improvements
+************
+
+* pull now takes --verbose to show you what revisions are added or removed
+ (John A Meinel)
+
+* merge now takes a --show-base option to include the base text in
+ conflicts.
+ (Aaron Bentley)
+
+* The config files are now read using ConfigObj, so '=' should be used as
+ a separator, not ':'.
+ (Aaron Bentley)
+
+* New 'bzr commit --strict' option refuses to commit if there are
+ any unknown files in the tree. To commit, make sure all files are
+ either ignored, added, or deleted. (Michael Ellerman)
+
+* The config directory is now ~/.bazaar, and there is a single file
+ ~/.bazaar/bazaar.conf storing email, editor and other preferences.
+ (Robert Collins)
+
+* 'bzr add' no longer takes a --verbose option, and a --quiet option
+ has been added that suppresses all output.
+
+* Improved zsh completion support in contrib/zsh, from Clint
+ Adams.
+
+* Builtin 'bzr annotate' command, by Martin Pool with improvements from
+ Goffredo Baroncelli.
+
+* 'bzr check' now accepts -v for verbose reporting, and checks for
+ ghosts in the branch. (Robert Collins)
+
+* New command 're-sign' which will regenerate the gpg signature for
+ a revision. (Robert Collins)
+
+* If you set ``check_signatures=require`` for a path in
+ ``~/.bazaar/branches.conf`` then bzr will invoke your
+ ``gpg_signing_command`` (defaults to gpg) and record a digital signature
+ of your commit. (Robert Collins)
+
+* New SFTP transport, based on Paramiko. (Robey Pointer)
+
+* 'bzr pull' now accepts '--clobber' which will discard local changes
+ and make this branch identical to the source branch. (Robert Collins)
+
+* Just give a quieter warning if a plugin can't be loaded, and
+ put the details in .bzr.log. (Martin Pool)
+
+* 'bzr branch' will now set the branch-name to the last component of the
+ output directory, if one was supplied.
+
+* If the option ``post_commit`` is set to one (or more) python function
+ names (must be in the bzrlib namespace), then they will be invoked
+ after the commit has completed, with the branch and ``revision_id`` as
+ parameters. (Robert Collins)
+
+* Merge now has a retcode of 1 when conflicts occur. (Robert Collins)
+
+* --merge-type weave is now supported for file contents. Tree-shape
+ changes are still three-way based. (Martin Pool, Aaron Bentley)
+
+* 'bzr check' allows the first revision on revision-history to have
+ parents - something that is expected for cheap checkouts, and occurs
+ when conversions from baz do not have all history. (Robert Collins).
+
+* 'bzr merge' can now graft unrelated trees together, if your specify
+ 0 as a base. (Aaron Bentley)
+
+* 'bzr commit branch' and 'bzr commit branch/file1 branch/file2' now work
+ (Aaron Bentley)
+
+* Add '.sconsign*' to default ignore list. (Alexander Belchenko)
+
+* 'bzr merge --reprocess' minimizes conflicts
+
+Testing
+*******
+
+* The 'bzr selftest --pattern' option for has been removed, now
+ test specifiers on the command line can be simple strings, or
+ regexps, or both. (Robert Collins)
+
+* Passing -v to selftest will now show the time each test took to
+ complete, which will aid in analysing performance regressions and
+ related questions. (Robert Collins)
+
+* 'bzr selftest' runs all tests, even if one fails, unless '--one'
+ is given. (Martin Pool)
+
+* There is a new method for TestCaseInTempDir, assertFileEqual, which
+ will check that a given content is equal to the content of the named
+ file. (Robert Collins)
+
+* Fix test suite's habit of leaving many temporary log files in $TMPDIR.
+ (Martin Pool)
+
+Internals
+*********
+
+* New 'testament' command and concept for making gpg-signatures
+ of revisions that are not tied to a particular internal
+ representation. (Martin Pool).
+
+* Per-revision properties ('revprops') as key-value associated
+ strings on each revision created when the revision is committed.
+ Intended mainly for the use of external tools. (Martin Pool).
+
+* Config options have moved from bzrlib.osutils to bzrlib.config.
+ (Robert Collins)
+
+* Improved command line option definitions allowing explanations
+ for individual options, among other things. Contributed by
+ Magnus Therning.
+
+* Config options have moved from bzrlib.osutils to bzrlib.config.
+ Configuration is now done via the config.Config interface:
+ Depending on whether you have a Branch, a Location or no information
+ available, construct a ``*Config``, and use its ``signature_checking``,
+ ``username`` and ``user_email`` methods. (Robert Collins)
+
+* Plugins are now loaded under bzrlib.plugins, not bzrlib.plugin, and
+ they are made available for other plugins to use. You should not
+ import other plugins during the ``__init__`` of your plugin though, as
+ no ordering is guaranteed, and the plugins directory is not on the
+ python path. (Robert Collins)
+
+* Branch.relpath has been moved to WorkingTree.relpath. WorkingTree no
+ no longer takes an inventory, rather it takes an option branch
+ parameter, and if None is given will open the branch at basedir
+ implicitly. (Robert Collins)
+
+* Cleaner exception structure and error reporting. Suggested by
+ Scott James Remnant. (Martin Pool)
+
+* Branch.remove has been moved to WorkingTree, which has also gained
+ ``lock_read``, ``lock_write`` and ``unlock`` methods for convenience.
+ (Robert Collins)
+
+* Two decorators, ``needs_read_lock`` and ``needs_write_lock`` have been
+ added to the branch module. Use these to cause a function to run in a
+ read or write lock respectively. (Robert Collins)
+
+* ``Branch.open_containing`` now returns a tuple (Branch, relative-path),
+ which allows direct access to the common case of 'get me this file
+ from its branch'. (Robert Collins)
+
+* Transports can register using ``register_lazy_transport``, and they
+ will be loaded when first used. (Martin Pool)
+
+* 'pull' has been factored out of the command as ``WorkingTree.pull()``.
+ A new option to WorkingTree.pull has been added, clobber, which will
+ ignore diverged history and pull anyway.
+ (Robert Collins)
+
+* config.Config has a ``get_user_option`` call that accepts an option name.
+ This will be looked up in branches.conf and bazaar.conf as normal.
+ It is intended that this be used by plugins to support options -
+ options of built in programs should have specific methods on the config.
+ (Robert Collins)
+
+* ``merge.merge_inner`` now has tempdir as an optional parameter.
+ (Robert Collins)
+
+* Tree.kind is not recorded at the top level of the hierarchy, as it was
+ missing on EmptyTree, leading to a bug with merge on EmptyTrees.
+ (Robert Collins)
+
+* ``WorkingTree.__del__`` has been removed, it was non deterministic and not
+ doing what it was intended to. See ``WorkingTree.__init__`` for a comment
+ about future directions. (Robert Collins/Martin Pool)
+
+* bzrlib.transport.http has been modified so that only 404 urllib errors
+ are returned as NoSuchFile. Other exceptions will propagate as normal.
+ This allows debuging of actual errors. (Robert Collins)
+
+* bzrlib.transport.Transport now accepts *ONLY* URL-escaped relative paths
+ to apis like 'put', 'get' and 'has'. This is to provide consistent
+ behaviour - it operates on URLs only. (Robert Collins)
+
+* Transports can register using ``register_lazy_transport``, and they
+ will be loaded when first used. (Martin Pool)
+
+* ``merge_flex`` no longer calls ``conflict_handler.finalize()``, instead that
+ is called by ``merge_inner``. This is so that the conflict count can be
+ retrieved (and potentially manipulated) before returning to the caller
+ of ``merge_inner``. Likewise 'merge' now returns the conflict count to the
+ caller. (Robert Collins)
+
+* ``revision.revision_graph`` can handle having only partial history for
+ a revision - that is no revisions in the graph with no parents.
+ (Robert Collins).
+
+* New ``builtins.branch_files`` uses the standard ``file_list`` rules to
+ produce a branch and a list of paths, relative to that branch
+ (Aaron Bentley)
+
+* New TestCase.addCleanup facility.
+
+* New ``bzrlib.version_info`` tuple (similar to ``sys.version_info``),
+ which can be used by programs importing bzrlib.
+
+Bug Fixes
+*********
+
+* Better handling of branches in directories with non-ascii names.
+ (Joel Rosdahl, Panagiotis Papadakos)
+
+* Upgrades of trees with no commits will not fail due to accessing
+ [-1] in the revision-history. (Andres Salomon)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.7.txt b/doc/en/release-notes/bzr-0.7.txt
new file mode 100644
index 0000000..9ce4be2
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.7.txt
@@ -0,0 +1,308 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.7
+#######
+
+:Released: 2006-01-09
+
+Changes
+*******
+
+* .bzrignore is excluded from exports, on the grounds that it's a bzr
+ internal-use file and may not be wanted. (Jamie Wilkinson)
+
+* The "bzr directories" command were removed in favor of the new
+ --kind option to the "bzr inventory" command. To list all
+ versioned directories, now use "bzr inventory --kind directory".
+ (Johan Rydberg)
+
+* Under Windows configuration directory is now ``%APPDATA%\bazaar\2.0``
+ by default. (John Arbash Meinel)
+
+* The parent of Bzr configuration directory can be set by ``BZR_HOME``
+ environment variable. Now the path for it is searched in ``BZR_HOME``,
+ then in HOME. Under Windows the order is: ``BZR_HOME``, ``APPDATA``
+ (usually points to ``C:\Documents and Settings\User Name\Application Data``),
+ ``HOME``. (John Arbash Meinel)
+
+* Plugins with the same name in different directories in the bzr plugin
+ path are no longer loaded: only the first successfully loaded one is
+ used. (Robert Collins)
+
+* Use system's external SSH command to open connections if possible.
+ This gives better integration with user settings such as ProxyCommand.
+ (James Henstridge)
+
+* Permissions on files underneath .bzr/ are inherited from the .bzr
+ directory. So for a shared repository, simply doing 'chmod -R g+w .bzr/'
+ will mean that future file will be created with group write permissions.
+
+* configure.in and config.guess are no longer in the builtin default
+ ignore list.
+
+* '.sw[nop]' pattern ignored, to ignore vim swap files for nameless
+ files. (John Arbash Meinel, Martin Pool)
+
+Improvements
+************
+
+* "bzr INIT dir" now initializes the specified directory, and creates
+ it if it does not exist. (John Arbash Meinel)
+
+* New remerge command (Aaron Bentley)
+
+* Better zsh completion script. (Steve Borho)
+
+* 'bzr diff' now returns 1 when there are changes in the working
+ tree. (Robert Collins)
+
+* 'bzr push' now exists and can push changes to a remote location.
+ This uses the transport infrastructure, and can store the remote
+ location in the ~/.bazaar/branches.conf configuration file.
+ (Robert Collins)
+
+* Test directories are only kept if the test fails and the user requests
+ that they be kept.
+
+* Tweaks to short log printing
+
+* Added branch nicks, new nick command, printing them in log output.
+ (Aaron Bentley)
+
+* If ``$BZR_PDB`` is set, pop into the debugger when an uncaught exception
+ occurs. (Martin Pool)
+
+* Accept 'bzr resolved' (an alias for 'bzr resolve'), as this is
+ the same as Subversion. (Martin Pool)
+
+* New FTP transport support (on ftplib), for ftp:// and aftp://
+ URLs. (Daniel Silverstone)
+
+* Commit editor temporary files now start with ``bzr_log.``, to allow
+ text editors to match the file name and set up appropriate modes or
+ settings. (Magnus Therning)
+
+* Improved performance when integrating changes from a remote weave.
+ (Goffredo Baroncelli)
+
+* Sftp will attempt to cache the connection, so it is more likely that
+ a connection will be reused, rather than requiring multiple password
+ requests.
+
+* bzr revno now takes an optional argument indicating the branch whose
+ revno should be printed. (Michael Ellerman)
+
+* bzr cat defaults to printing the last version of the file.
+ (Matthieu Moy, #3632)
+
+* New global option 'bzr --lsprof COMMAND' runs bzr under the lsprof
+ profiler. (Denys Duchier)
+
+* Faster commits by reading only the headers of affected weave files.
+ (Denys Duchier)
+
+* 'bzr add' now takes a --dry-run parameter which shows you what would be
+ added, but doesn't actually add anything. (Michael Ellerman)
+
+* 'bzr add' now lists how many files were ignored per glob. add --verbose
+ lists the specific files. (Aaron Bentley)
+
+* 'bzr missing' now supports displaying changes in diverged trees and can
+ be limited to show what either end of the comparison is missing.
+ (Aaron Bently, with a little prompting from Daniel Silverstone)
+
+Bug Fixes
+*********
+
+* SFTP can walk up to the root path without index errors. (Robert Collins)
+
+* Fix bugs in running bzr with 'python -O'. (Martin Pool)
+
+* Error when run with -OO
+
+* Fix bug in reporting HTTP errors that don't have an HTTP error code.
+ (Martin Pool)
+
+* Handle more cases of pipe errors in display commands
+
+* Change status to 3 for all errors
+
+* Files that are added and unlinked before committing are completely
+ ignored by diff and status
+
+* Stores with some compressed texts and some uncompressed texts are now
+ able to be used. (John A Meinel)
+
+* Fix for bzr pull failing sometimes under windows
+
+* Fix for SFTP transport under windows when using interactive auth
+
+* Show files which are both renamed and modified as such in 'bzr
+ status' output. (Daniel Silverstone, #4503)
+
+* Make annotate cope better with revisions committed without a valid
+ email address. (Marien Zwart)
+
+* Fix representation of tab characters in commit messages.
+ (Harald Meland)
+
+* List of plugin directories in ``BZR_PLUGIN_PATH`` environment variable is
+ now parsed properly under Windows. (Alexander Belchenko)
+
+* Show number of revisions pushed/pulled/merged. (Robey Pointer)
+
+* Keep a cached copy of the basis inventory to speed up operations
+ that need to refer to it. (Johan Rydberg, Martin Pool)
+
+* Fix bugs in bzr status display of non-ascii characters.
+ (Martin Pool)
+
+* Remove Makefile.in from default ignore list.
+ (Tollef Fog Heen, Martin Pool, #6413)
+
+* Fix failure in 'bzr added'. (Nathan McCallum, Martin Pool)
+
+Testing
+*******
+
+* Fix selftest asking for passwords when there are no SFTP keys.
+ (Robey Pointer, Jelmer Vernooij)
+
+* Fix selftest run with 'python -O'. (Martin Pool)
+
+* Fix HTTP tests under Windows. (John Arbash Meinel)
+
+* Make tests work even if HOME is not set (Aaron Bentley)
+
+* Updated ``build_tree`` to use fixed line-endings for tests which read
+ the file cotents and compare. Make some tests use this to pass under
+ Windows. (John Arbash Meinel)
+
+* Skip stat and symlink tests under Windows. (Alexander Belchenko)
+
+* Delay in selftest/testhashcash is now issued under win32 and Cygwin.
+ (John Arbash Meinel)
+
+* Use terminal width to align verbose test output. (Martin Pool)
+
+* Blackbox tests are maintained within the bzrlib.tests.blackbox directory.
+ If adding a new test script please add that to
+ ``bzrlib.tests.blackbox.__init__``. (Robert Collins)
+
+* Much better error message if one of the test suites can't be
+ imported. (Martin Pool)
+
+* Make check now runs the test suite twice - once with the default locale,
+ and once with all locales forced to C, to expose bugs. This is not
+ trivially done within python, so for now its only triggered by running
+ Make check. Integrators and packagers who wish to check for full
+ platform support should run 'make check' to test the source.
+ (Robert Collins)
+
+* Tests can now run TestSkipped if they can't execute for any reason.
+ (Martin Pool) (NB: TestSkipped should only be raised for correctable
+ reasons - see the wiki spec ImprovingBzrTestSuite).
+
+* Test SFTP with relative, absolute-in-homedir and absolute-not-in-homedir
+ paths for the transport tests. Introduce blackbox remote SFTP tests that
+ test the same permutations. (Robert Collins, Robey Pointer)
+
+* Transport implementation tests are now independent of the local file
+ system, which allows tests for esoteric transports, and for features
+ not available in the local file system. They also repeat for variations
+ on the URL scheme that can introduce issues in the transport code,
+ see bzrlib.transport.TransportTestProviderAdapter() for this.
+ (Robert Collins).
+
+* ``TestCase.build_tree`` uses the transport interface to build trees,
+ pass in a transport parameter to give it an existing connection.
+ (Robert Collins).
+
+Internals
+*********
+
+* WorkingTree.pull has been split across Branch and WorkingTree,
+ to allow Branch only pulls. (Robert Collins)
+
+* ``commands.display_command`` now returns the result of the decorated
+ function. (Robert Collins)
+
+* LocationConfig now has a ``set_user_option(key, value)`` call to save
+ a setting in its matching location section (a new one is created
+ if needed). (Robert Collins)
+
+* Branch has two new methods, ``get_push_location`` and
+ ``set_push_location`` to respectively, get and set the push location.
+ (Robert Collins)
+
+* ``commands.register_command`` now takes an optional flag to signal that
+ the registrant is planning to decorate an existing command. When
+ given multiple plugins registering a command is not an error, and
+ the original command class (whether built in or a plugin based one) is
+ returned to the caller. There is a new error 'MustUseDecorated' for
+ signalling when a wrapping command should switch to the original
+ version. (Robert Collins)
+
+* Some option parsing errors will raise 'BzrOptionError', allowing
+ granular detection for decorating commands. (Robert Collins).
+
+* ``Branch.read_working_inventory`` has moved to
+ ``WorkingTree.read_working_inventory``. This necessitated changes to
+ ``Branch.get_root_id``, and a move of ``Branch.set_inventory`` to
+ WorkingTree as well. To make it clear that a WorkingTree cannot always
+ be obtained ``Branch.working_tree()`` will raise
+ ``errors.NoWorkingTree`` if one cannot be obtained. (Robert Collins)
+
+* All pending merges operations from Branch are now on WorkingTree.
+ (Robert Collins)
+
+* The follow operations from Branch have moved to WorkingTree::
+
+ add()
+ commit()
+ move()
+ rename_one()
+ unknowns()
+
+ (Robert Collins)
+
+* ``bzrlib.add.smart_add_branch`` is now ``smart_add_tree``. (Robert Collins)
+
+* New "rio" serialization format, similar to rfc-822. (Martin Pool)
+
+* Rename selftests to ``bzrlib.tests.test_foo``. (John A Meinel, Martin
+ Pool)
+
+* ``bzrlib.plugin.all_plugins`` has been changed from an attribute to a
+ query method. (Robert Collins)
+
+* New options to read only the table-of-contents of a weave.
+ (Denys Duchier)
+
+* Raise NoSuchFile when someone tries to add a non-existant file.
+ (Michael Ellerman)
+
+* Simplify handling of DivergedBranches in ``cmd_pull()``.
+ (Michael Ellerman)
+
+* Branch.controlfile* logic has moved to lockablefiles.LockableFiles, which
+ is exposed as ``Branch().control_files``. Also this has been altered with the
+ controlfile pre/suffix replaced by simple method names like 'get' and
+ 'put'. (Aaron Bentley, Robert Collins).
+
+* Deprecated functions and methods can now be marked as such using the
+ ``bzrlib.symbol_versioning`` module. Marked method have their docstring
+ updated and will issue a DeprecationWarning using the warnings module
+ when they are used. (Robert Collins)
+
+* ``bzrlib.osutils.safe_unicode`` now exists to provide parameter coercion
+ for functions that need unicode strings. (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.8.txt b/doc/en/release-notes/bzr-0.8.txt
new file mode 100644
index 0000000..20b6d8f
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.8.txt
@@ -0,0 +1,340 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.8.2
+#########
+
+:Released: 2006-05-17
+
+Bug Fixes
+*********
+
+* setup.py failed to install launchpad plugin. (Martin Pool)
+
+bzr 0.8.1
+#########
+
+:Released: 2006-05-16
+
+Bug Fixes
+*********
+
+* Fix failure to commit a merge in a checkout. (Martin Pool,
+ Robert Collins, Erik Bågfors, #43959)
+
+* Nicer messages from 'commit' in the case of renames, and correct
+ messages when a merge has occured. (Robert Collins, Martin Pool)
+
+* Separate functionality from assert statements as they are skipped in
+ optimized mode of python. Add the same check to pending merges.
+ (Olaf Conradi, #44443)
+
+Changes
+*******
+
+* Do not show the None revision in output of bzr ancestry. (Olaf Conradi)
+
+* Add info on standalone branches without a working tree.
+ (Olaf Conradi, #44155)
+
+* Fix bug in knits when raising InvalidRevisionId. (Olaf Conradi, #44284)
+
+Changes
+*******
+
+* Make editor invocation comply with Debian Policy. First check
+ environment variables VISUAL and EDITOR, then try editor from
+ alternatives system. If that all fails, fall back to the pre-defined
+ list of editors. (Olaf Conradi, #42904)
+
+New Features
+************
+
+* New 'register-branch' command registers a public branch into
+ Launchpad.net, where it can be associated with bugs, etc.
+ (Martin Pool, Bjorn Tillenius, Robert Collins)
+
+Internals
+*********
+
+* New public api in InventoryEntry - ``describe_change(old, new)`` which
+ provides a human description of the changes between two old and
+ new. (Robert Collins, Martin Pool)
+
+Testing
+*******
+
+* Fix test case for bzr info in upgrading a standalone branch to metadir,
+ uses bzrlib api now. (Olaf Conradi)
+
+bzr 0.8
+#######
+
+:Released: 2006-05-08
+
+Notes When Upgrading
+********************
+
+Release 0.8 of bzr introduces a new format for history storage, called
+'knit', as an evolution of to the 'weave' format used in 0.7. Local
+and remote operations are faster using knits than weaves. Several
+operations including 'init', 'init-repo', and 'upgrade' take a
+--format option that controls this. Branching from an existing branch
+will keep the same format.
+
+It is possible to merge, pull and push between branches of different
+formats but this is slower than moving data between homogenous
+branches. It is therefore recommended (but not required) that you
+upgrade all branches for a project at the same time. Information on
+formats is shown by 'bzr info'.
+
+bzr 0.8 now allows creation of 'repositories', which hold the history
+of files and revisions for several branches. Previously bzr kept all
+the history for a branch within the .bzr directory at the root of the
+branch, and this is still the default. To create a repository, use
+the new 'bzr init-repo' command. Branches exist as directories under
+the repository and contain just a small amount of information
+indicating the current revision of the branch.
+
+bzr 0.8 also supports 'checkouts', which are similar to in cvs and
+subversion. Checkouts are associated with a branch (optionally in a
+repository), which contains all the historical information. The
+result is that a checkout can be deleted without losing any
+already-committed revisions. A new 'update' command is also available.
+
+Repositories and checkouts are not supported with the 0.7 storage
+format. To use them you must upgrad to either knits, or to the
+'metaweave' format, which uses weaves but changes the .bzr directory
+arrangement.
+
+
+Improvements
+************
+
+* SFTP paths can now be relative, or local, according to the lftp
+ convention. Paths now take the form::
+
+ sftp://user:pass@host:port/~/relative/path
+ or
+ sftp://user:pass@host:port/absolute/path
+
+* The FTP transport now tries to reconnect after a temporary
+ failure. FTP put is made atomic. (Matthieu Moy)
+
+* The FTP transport now maintains a pool of connections, and
+ reuses them to avoid multiple connections to the same host (like
+ SFTP did). (Daniel Silverstone)
+
+* The ``bzr_man.py`` file has been removed. To create the man page now,
+ use ``./generate_docs.py man``. The new program can also create other files.
+ Run ``python generate_docs.py --help`` for usage information.
+ (Hans Ulrich Niedermann & James Blackwell).
+
+* Man Page now gives full help (James Blackwell).
+ Help also updated to reflect user config now being stored in .bazaar
+ (Hans Ulrich Niedermann)
+
+* It's now possible to set aliases in bazaar.conf (Erik Bågfors)
+
+* Pull now accepts a --revision argument (Erik Bågfors)
+
+* ``bzr re-sign`` now allows multiple revisions to be supplied on the command
+ line. You can now use the following command to sign all of your old
+ commits::
+
+ find .bzr/revision-store// -name my@email-* \
+ | sed 's/.*\/\/..\///' \
+ | xargs bzr re-sign
+
+* Upgrade can now upgrade over the network. (Robert Collins)
+
+* Two new commands 'bzr checkout' and 'bzr update' allow for CVS/SVN-alike
+ behaviour. By default they will cache history in the checkout, but
+ with --lightweight almost all data is kept in the master branch.
+ (Robert Collins)
+
+* 'revert' unversions newly-versioned files, instead of deleting them.
+
+* 'merge' is more robust. Conflict messages have changed.
+
+* 'merge' and 'revert' no longer clobber existing files that end in '~' or
+ '.moved'.
+
+* Default log format can be set in configuration and plugins can register
+ their own formatters. (Erik Bågfors)
+
+* New 'reconcile' command will check branch consistency and repair indexes
+ that can become out of sync in pre 0.8 formats. (Robert Collins,
+ Daniel Silverstone)
+
+* New 'bzr init --format' and 'bzr upgrade --format' option to control
+ what storage format is created or produced. (Robert Collins,
+ Martin Pool)
+
+* Add parent location to 'bzr info', if there is one. (Olaf Conradi)
+
+* New developer commands 'weave-list' and 'weave-join'. (Martin Pool)
+
+* New 'init-repository' command, plus support for repositories in 'init'
+ and 'branch' (Aaron Bentley, Erik Bågfors, Robert Collins)
+
+* Improve output of 'info' command. Show all relevant locations related to
+ working tree, branch and repository. Use kibibytes for binary quantities.
+ Fix off-by-one error in missing revisions of working tree. Make 'info'
+ work on branches, repositories and remote locations. Show locations
+ relative to the shared repository, if applicable. Show locking status
+ of locations. (Olaf Conradi)
+
+* Diff and merge now safely handle binary files. (Aaron Bentley)
+
+* 'pull' and 'push' now normalise the revision history, so that any two
+ branches with the same tip revision will have the same output from 'log'.
+ (Robert Collins)
+
+* 'merge' accepts --remember option to store parent location, like 'push'
+ and 'pull'. (Olaf Conradi)
+
+* bzr status and diff when files given as arguments do not exist
+ in the relevant trees. (Martin Pool, #3619)
+
+* Add '.hg' to the default ignore list. (Martin Pool)
+
+* 'knit' is now the default disk format. This improves disk performance and
+ utilization, increases incremental pull performance, robustness with SFTP
+ and allows checkouts over SFTP to perform acceptably.
+ The initial Knit code was contributed by Johan Rydberg based on a
+ specification by Martin Pool.
+ (Robert Collins, Aaron Bentley, Johan Rydberg, Martin Pool).
+
+* New tool to generate all-in-one html version of the manual. (Alexander
+ Belchenko)
+
+* Hitting CTRL-C while doing an SFTP push will no longer cause stale locks
+ to be left in the SFTP repository. (Robert Collins, Martin Pool).
+
+* New option 'diff --prefix' to control how files are named in diff
+ output, with shortcuts '-p0' and '-p1' corresponding to the options for
+ GNU patch. (Alexander Belchenko, Goffredo Baroncelli, Martin Pool)
+
+* Add --revision option to 'annotate' command. (Olaf Conradi)
+
+* If bzr shows an unexpected revision-history after pulling (perhaps due
+ to a reweave) it can now be corrected by 'bzr reconcile'.
+ (Robert Collins)
+
+Changes
+*******
+
+* Commit is now verbose by default, and shows changed filenames and the
+ new revision number. (Robert Collins, Martin Pool)
+
+* Unify 'mv', 'move', 'rename'. (Matthew Fuller, #5379)
+
+* 'bzr -h' shows help. (Martin Pool, Ian Bicking, #35940)
+
+* Make 'pull' and 'push' remember location on failure using --remember.
+ (Olaf Conradi)
+
+* For compatibility, make old format for using weaves inside metadir
+ available as 'metaweave' format. Rename format 'metadir' to 'default'.
+ Clean up help for option --format in commands 'init', 'init-repo' and
+ 'upgrade'. (Olaf Conradi)
+
+Internals
+*********
+
+* The internal storage of history, and logical branch identity have now
+ been split into Branch, and Repository. The common locking and file
+ management routines are now in bzrlib.lockablefiles.
+ (Aaron Bentley, Robert Collins, Martin Pool)
+
+* Transports can now raise DependencyNotPresent if they need a library
+ which is not installed, and then another implementation will be
+ tried. (Martin Pool)
+
+* Remove obsolete (and no-op) `decode` parameter to `Transport.get`.
+ (Martin Pool)
+
+* Using Tree Transform for merge, revert, tree-building
+
+* WorkingTree.create, Branch.create, ``WorkingTree.create_standalone``,
+ Branch.initialize are now deprecated. Please see ``BzrDir.create_*`` for
+ replacement API's. (Robert Collins)
+
+* New BzrDir class represents the .bzr control directory and manages
+ formatting issues. (Robert Collins)
+
+* New repository.InterRepository class encapsulates Repository to
+ Repository actions and allows for clean selection of optimised code
+ paths. (Robert Collins)
+
+* ``bzrlib.fetch.fetch`` and ``bzrlib.fetch.greedy_fetch`` are now
+ deprecated, please use ``branch.fetch`` or ``repository.fetch``
+ depending on your needs. (Robert Collins)
+
+* deprecated methods now have a ``is_deprecated`` flag on them that can
+ be checked, if you need to determine whether a given callable is
+ deprecated at runtime. (Robert Collins)
+
+* Progress bars are now nested - see
+ ``bzrlib.ui.ui_factory.nested_progress_bar``.
+ (Robert Collins, Robey Pointer)
+
+* New API call ``get_format_description()`` for each type of format.
+ (Olaf Conradi)
+
+* Changed ``branch.set_parent()`` to accept None to remove parent.
+ (Olaf Conradi)
+
+* Deprecated BzrError AmbiguousBase. (Olaf Conradi)
+
+* WorkingTree.branch is now a read only property. (Robert Collins)
+
+* bzrlib.ui.text.TextUIFactory now accepts a ``bar_type`` parameter which
+ can be None or a factory that will create a progress bar. This is
+ useful for testing or for overriding the bzrlib.progress heuristic.
+ (Robert Collins)
+
+* New API method ``get_physical_lock_status()`` to query locks present on a
+ transport. (Olaf Conradi)
+
+* Repository.reconcile now takes a thorough keyword parameter to allow
+ requesting an indepth reconciliation, rather than just a data-loss
+ check. (Robert Collins)
+
+* ``bzrlib.ui.ui_factory protocol`` now supports ``get_boolean`` to prompt
+ the user for yes/no style input. (Robert Collins)
+
+Testing
+*******
+
+* SFTP tests now shortcut the SSH negotiation, reducing test overhead
+ for testing SFTP protocol support. (Robey Pointer)
+
+* Branch formats are now tested once per implementation (see ``bzrlib.
+ tests.branch_implementations``. This is analagous to the transport
+ interface tests, and has been followed up with working tree,
+ repository and BzrDir tests. (Robert Collins)
+
+* New test base class TestCaseWithTransport provides a transport aware
+ test environment, useful for testing any transport-interface using
+ code. The test suite option --transport controls the transport used
+ by this class (when its not being used as part of implementation
+ contract testing). (Robert Collins)
+
+* Close logging handler on disabling the test log. This will remove the
+ handler from the internal list inside python's logging module,
+ preventing shutdown from closing it twice. (Olaf Conradi)
+
+* Move test case for uncommit to blackbox tests. (Olaf Conradi)
+
+* ``run_bzr`` and ``run_bzr_captured`` now accept a 'stdin="foo"'
+ parameter which will provide String("foo") to the command as its stdin.
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.9.txt b/doc/en/release-notes/bzr-0.9.txt
new file mode 100644
index 0000000..7db9268
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.9.txt
@@ -0,0 +1,280 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.9.0
+#########
+
+:Released: 2006-08-11
+
+Surprises
+*********
+
+* The hard-coded built-in ignore rules have been removed. There are
+ now two rulesets which are enforced. A user global one in
+ ``~/.bazaar/ignore`` which will apply to every tree, and the tree
+ specific one '.bzrignore'.
+ ``~/.bazaar/ignore`` will be created if it does not exist, but with
+ a more conservative list than the old default.
+ This fixes bugs with default rules being enforced no matter what.
+ The old list of ignore rules from bzr is available by
+ running 'bzr ignore --old-default-rules'.
+ (Robert Collins, Martin Pool, John Arbash Meinel)
+
+* 'branches.conf' has been changed to 'locations.conf', since it can apply
+ to more locations than just branch locations.
+ (Aaron Bentley)
+
+Improvements
+************
+
+* The revision specifier "revno:" is extended to accept the syntax
+ revno:N:branch. For example,
+ revno:42:http://bazaar-vcs.org/bzr/bzr.dev/ means revision 42 in
+ bzr.dev. (Matthieu Moy)
+
+* Tests updates to ensure proper URL handling, UNICODE support, and
+ proper printing when the user's terminal encoding cannot display
+ the path of a file that has been versioned.
+ ``bzr branch`` can take a target URL rather than only a local directory.
+ ``Branch.get_parent()/set_parent()`` now save a relative path if possible,
+ and normalize the parent based on root, allowing access across
+ different transports. (John Arbash Meinel, Wouter van Heyst, Martin Pool)
+ (Malone #48906, #42699, #40675, #5281, #3980, #36363, #43689,
+ #42517, #42514)
+
+* On Unix, detect terminal width using an ioctl not just $COLUMNS.
+ Use terminal width for single-line logs from ``bzr log --line`` and
+ pending-merge display. (Robert Widhopf-Fenk, Gustavo Niemeyer)
+ (Malone #3507)
+
+* On Windows, detect terminal width using GetConsoleScreenBufferInfo.
+ (Alexander Belchenko)
+
+* Speedup improvement for 'date:'-revision search. (Guillaume Pinot).
+
+* Show the correct number of revisions pushed when pushing a new branch.
+ (Robert Collins).
+
+* 'bzr selftest' now shows a progress bar with the number of tests, and
+ progress made. 'make check' shows tests in -v mode, to be more useful
+ for the PQM status window. (Robert Collins).
+ When using a progress bar, failed tests are printed out, rather than
+ being overwritten by the progress bar until the suite finishes.
+ (John Arbash Meinel)
+
+* 'bzr selftest --benchmark' will run a new benchmarking selftest.
+ 'bzr selftest --benchmark --lsprof-timed' will use lsprofile to generate
+ profile data for the individual profiled calls, allowing for fine
+ grained analysis of performance.
+ (Robert Collins, Martin Pool).
+
+* 'bzr commit' shows a progress bar. This is useful for commits over SFTP
+ where commit can take an appreciable time. (Robert Collins)
+
+* 'bzr add' is now less verbose in telling you what ignore globs were
+ matched by files being ignored. Instead it just tells you how many
+ were ignored (because you might reasonably be expecting none to be
+ ignored). 'bzr add -v' is unchanged and will report every ignored
+ file. (Robert Collins).
+
+* FTP now has a test server if medusa is installed. As part of testing,
+ FTP support has been improved, including support for supplying a
+ non-standard port. (John Arbash Meinel).
+
+* 'bzr log --line' shows the revision number, and uses only the
+ first line of the log message (#5162, Alexander Belchenko;
+ Matthieu Moy)
+
+* 'bzr status' has had the --all option removed. The 'bzr ls' command
+ should be used to retrieve all versioned files. (Robert Collins)
+
+* 'bzr bundle OTHER/BRANCH' will create a bundle which can be sent
+ over email, and applied on the other end, while maintaining ancestry.
+ This bundle can be applied with either 'bzr merge' or 'bzr pull',
+ the same way you would apply another branch.
+ (John Arbash Meinel, Aaron Bentley)
+
+* 'bzr whoami' can now be used to set your identity from the command line,
+ for a branch or globally. (Robey Pointer)
+
+* 'bzr checkout' now aliased to 'bzr co', and 'bzr annotate' to 'bzr ann'.
+ (Michael Ellerman)
+
+* 'bzr revert DIRECTORY' now reverts the contents of the directory as well.
+ (Aaron Bentley)
+
+* 'bzr get sftp://foo' gives a better error when paramiko is not present.
+ Also updates things like 'http+pycurl://' if pycurl is not present.
+ (John Arbash Meinel) (Malone #47821, #52204)
+
+* New env variable ``BZR_PROGRESS_BAR``, sets the default progress bar type.
+ Can be set to 'none' or 'dummy' to disable the progress bar, 'dots' or
+ 'tty' to create the respective type. (John Arbash Meinel, #42197, #51107)
+
+* Improve the help text for 'bzr diff' to explain what various options do.
+ (John Arbash Meinel, #6391)
+
+* 'bzr uncommit -r 10' now uncommits revisions 11.. rather than uncommitting
+ revision 10. This makes -r10 more in line with what other commands do.
+ 'bzr uncommit' also now saves the pending merges of the revisions that
+ were removed. So it is safe to uncommit after a merge, fix something,
+ and commit again. (John Arbash Meinel, #32526, #31426)
+
+* 'bzr init' now also works on remote locations.
+ (Wouter van Heyst, #48904)
+
+* HTTP support has been updated. When using pycurl we now support
+ connection keep-alive, which reduces dns requests and round trips.
+ And for both urllib and pycurl we support multi-range requests,
+ which decreases the number of round-trips. Performance results for
+ ``bzr branch http://bazaar-vcs.org/bzr/bzr.dev/`` indicate
+ HTTP branching is now 2-3x faster, and ``bzr pull`` in an existing
+ branch is as much as 4x faster.
+ (Michael Ellerman, Johan Rydberg, John Arbash Meinel, #46768)
+
+* Performance improvements for SFTP. Branching and pulling are now up to
+ 2x faster. Utilize paramiko.readv() support for async requests if it
+ is available (paramiko > 1.6) (John Arbash Meinel)
+
+Bug Fixes
+*********
+
+* Fix shadowed definition of TestLocationConfig that caused some
+ tests not to run.
+ (Erik Bågfors, Michael Ellerman, Martin Pool, #32587)
+
+* Fix unnecessary requirement of sign-my-commits that it be run from
+ a working directory. (Martin Pool, Robert Collins)
+
+* 'bzr push location' will only remember the push location if it succeeds
+ in connecting to the remote location. (John Arbash Meinel, #49742)
+
+* 'bzr revert' no longer toggles the executable bit on win32
+ (John Arbash Meinel, #45010)
+
+* Handle broken pipe under win32 correctly. (John Arbash Meinel)
+
+* SFTP tests now work correctly on win32 if you have a newer paramiko
+ (John Arbash Meinel)
+
+* Cleanup win32 test suite, and general cleanup of places where
+ file handles were being held open. (John Arbash Meinel)
+
+* When specifying filenames for 'diff -r x..y', the name of the file in the
+ working directory can be used, even if its name is different in both x
+ and y.
+
+* File-ids containing single- or double-quotes are handled correctly by
+ push. (Aaron Bentley, #52227)
+
+* Normalize unicode filenames to ensure cross-platform consistency.
+ (John Arbash Meinel, #43689)
+
+* The argument parser can now handle '-' as an argument. Currently
+ no code interprets it specially (it is mostly handled as a file named
+ '-'). But plugins, and future operations can use it.
+ (John Arbash meinel, #50984)
+
+* Bundles can properly read binary files with a plain '\r' in them.
+ (John Arbash Meinel, #51927)
+
+* Tuning ``iter_entries()`` to be more efficient (John Arbash Meinel, #5444)
+
+* Lots of win32 fixes (the test suite passes again).
+ (John Arbash Meinel, #50155)
+
+* Handle openbsd returning None for sys.getfilesystemencoding() (#41183)
+
+* Support FTP APPE (append) to allow Knits to be used over FTP (#42592)
+
+* Removals are only committed if they match the filespec (or if there is
+ no filespec). (#46635, Aaron Bentley)
+
+* smart-add recurses through all supplied directories
+ (John Arbash Meinel, #52578)
+
+* Make the bundle reader extra lines before and after the bundle text.
+ This allows you to parse an email with the bundle inline.
+ (John Arbash Meinel, #49182)
+
+* Change the file id generator to squash a little bit more. Helps when
+ working with long filenames on windows. (Also helps for unicode filenames
+ not generating hidden files). (John Arbash Meinel, #43801)
+
+* Restore terminal mode on C-c while reading SFTP password. (#48923,
+ Nicholas Allen, Martin Pool)
+
+* Timestamps are rounded to 1ms, and revision entries can be recreated
+ exactly. (John Arbash Meinel, Jamie Wilkinson, #40693)
+
+* Branch.base has changed to a URL, but ~/.bazaar/locations.conf should
+ use local paths, since it is user visible (John Arbash Meinel, #53653)
+
+* ``bzr status foo`` when foo was unversioned used to cause a full delta
+ to be generated (John Arbash Meinel, #53638)
+
+* When reading revision properties, an empty value should be considered
+ the empty string, not None (John Arbash Meinel, #47782)
+
+* ``bzr diff --diff-options`` can now handle binary files being changed.
+ Also, the output is consistent when --diff-options is not supplied.
+ (John Arbash Meinel, #54651, #52930)
+
+* Use the right suffixes for loading plugins (John Arbash Meinel, #51810)
+
+* Fix ``Branch.get_parent()`` to handle the case when the parent is not
+ accessible (John Arbash Meinel, #52976)
+
+Internals
+*********
+
+* Combine the ignore rules into a single regex rather than looping over
+ them to reduce the threshold where N^2 behaviour occurs in operations
+ like status. (Jan Hudec, Robert Collins).
+
+* Appending to ``bzrlib.DEFAULT_IGNORE`` is now deprecated. Instead, use
+ one of the add functions in bzrlib.ignores. (John Arbash Meinel)
+
+* 'bzr push' should only push the ancestry of the current revision, not
+ all of the history in the repository. This is especially important for
+ shared repositories. (John Arbash Meinel)
+
+* ``bzrlib.delta.compare_trees`` now iterates in alphabetically sorted order,
+ rather than randomly walking the inventories. (John Arbash Meinel)
+
+* Doctests are now run in temporary directories which are cleaned up when
+ they finish, rather than using special ScratchDir/ScratchBranch objects.
+ (Martin Pool)
+
+* Split ``check`` into separate methods on the branch and on the repository,
+ so that it can be specialized in ways that are useful or efficient for
+ different formats. (Martin Pool, Robert Collins)
+
+* Deprecate ``Repository.all_revision_ids``; most methods don't really need
+ the global revision graph but only that part leading up to a particular
+ revision. (Martin Pool, Robert Collins)
+
+* Add a BzrDirFormat ``control_formats`` list which allows for control formats
+ that do not use '.bzr' to store their data - i.e. '.svn', '.hg' etc.
+ (Robert Collins, Jelmer Vernooij).
+
+* ``bzrlib.diff.external_diff`` can be redirected to any file-like object.
+ Uses subprocess instead of spawnvp.
+ (James Henstridge, John Arbash Meinel, #4047, #48914)
+
+* New command line option '--profile-imports', which will install a custom
+ importer to log time to import modules and regex compilation time to
+ sys.stderr (John Arbash Meinel)
+
+* 'EmptyTree' is now deprecated, please use ``repository.revision_tree(None)``
+ instead. (Robert Collins)
+
+* "RevisionTree" is now in bzrlib/revisiontree.py. (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.90.txt b/doc/en/release-notes/bzr-0.90.txt
new file mode 100644
index 0000000..01cc258
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.90.txt
@@ -0,0 +1,311 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.90
+########
+
+:Released: 2007-08-28
+
+Improvements
+************
+
+* Documentation is now organized into multiple directories with a level
+ added for different languages or locales. Added the Mini Tutorial
+ and Quick Start Summary (en) documents from the Wiki, improving the
+ content and readability of the former. Formatted NEWS as Release Notes
+ complete with a Table of Conents, one heading per release. Moved the
+ Developer Guide into the main document catalog and provided a link
+ from the developer document catalog back to the main one.
+ (Ian Clatworthy, Sabin Iacob, Alexander Belchenko)
+
+
+API Changes
+***********
+
+* The static convenience method ``BzrDir.create_repository``
+ is deprecated. Callers should instead create a ``BzrDir`` instance
+ and call ``create_repository`` on that. (Martin Pool)
+
+
+bzr 0.90rc1
+###########
+
+:Released: 2007-08-14
+
+Bugfixes
+********
+
+* ``bzr init`` should connect to the remote location one time only. We
+ have been connecting several times because we forget to pass around the
+ Transport object. This modifies ``BzrDir.create_branch_convenience``,
+ so that we can give it the Transport we already have.
+ (John Arbash Meinel, Vincent Ladeuil, #111702)
+
+* Get rid of SFTP connection cache (get rid of the FTP one too).
+ (Vincent Ladeuil, #43731)
+
+* bzr branch {local|remote} remote don't try to create a working tree
+ anymore.
+ (Vincent Ladeuil, #112173)
+
+* All identified multiple connections for a single bzr command have been
+ fixed. See bzrlib/tests/commands directory.
+ (Vincent Ladeuil)
+
+* ``bzr rm`` now does not insist on ``--force`` to delete files that
+ have been renamed but not otherwise modified. (Marius Kruger,
+ #111664)
+
+* ``bzr selftest --bench`` no longer emits deprecation warnings
+ (Lukáš Lalinský)
+
+* ``bzr status`` now honours FILE parameters for conflict lists
+ (Aaron Bentley, #127606)
+
+* ``bzr checkout`` now honours -r when reconstituting a working tree.
+ It also honours -r 0. (Aaron Bentley, #127708)
+
+* ``bzr add *`` no more fails on Windows if working tree contains
+ non-ascii file names. (Kuno Meyer, #127361)
+
+* allow ``easy_install bzr`` runs without fatal errors.
+ (Alexander Belchenko, #125521)
+
+* Graph._filter_candidate_lca does not raise KeyError if a candidate
+ is eliminated just before it would normally be examined. (Aaron Bentley)
+
+* SMTP connection failures produce a nice message, not a traceback.
+ (Aaron Bentley)
+
+Improvements
+************
+
+* Don't show "dots" progress indicators when run non-interactively, such
+ as from cron. (Martin Pool)
+
+* ``info`` now formats locations more nicely and lists "submit" and
+ "public" branches (Aaron Bentley)
+
+* New ``pack`` command that will trigger database compression within
+ the repository (Robert Collins)
+
+* Implement ``_KnitIndex._load_data`` in a pyrex extension. The pyrex
+ version is approximately 2-3x faster at parsing a ``.kndx`` file.
+ Which yields a measurable improvement for commands which have to
+ read from the repository, such as a 1s => 0.75s improvement in
+ ``bzr diff`` when there are changes to be shown. (John Arbash Meinel)
+
+* Merge is now faster. Depending on the scenario, it can be more than 2x
+ faster. (Aaron Bentley)
+
+* Give a clearer warning, and allow ``python setup.py install`` to
+ succeed even if pyrex is not available.
+ (John Arbash Meinel)
+
+* ``DirState._read_dirblocks`` now has an optional Pyrex
+ implementation. This improves the speed of any command that has to
+ read the entire DirState. (``diff``, ``status``, etc, improve by
+ about 10%).
+ ``bisect_dirblocks`` has also been improved, which helps all
+ ``_get_entry`` type calls (whenever we are searching for a
+ particular entry in the in-memory DirState).
+ (John Arbash Meinel)
+
+* ``bzr pull`` and ``bzr push`` no longer do a complete walk of the
+ branch revision history for ui display unless -v is supplied.
+ (Robert Collins)
+
+* ``bzr log -rA..B`` output shifted to the left margin if the log only
+ contains merge revisions. (Kent Gibson)
+
+* The ``plugins`` command is now public with improved help.
+ (Ian Clatworthy)
+
+* New bundle and merge directive formats are faster to generate, and
+
+* Annotate merge now works when there are local changes. (Aaron Bentley)
+
+* Commit now only shows the progress in terms of directories instead of
+ entries. (Ian Clatworthy)
+
+* Fix ``KnitRepository.get_revision_graph`` to not request the graph 2
+ times. This makes ``get_revision_graph`` 2x faster. (John Arbash
+ Meinel)
+
+* Fix ``VersionedFile.get_graph()`` to avoid using
+ ``set.difference_update(other)``, which has bad scaling when
+ ``other`` is large. This improves ``VF.get_graph([version_id])`` for
+ a 12.5k graph from 2.9s down to 200ms. (John Arbash Meinel)
+
+* The ``--lsprof-file`` option now generates output for KCacheGrind if
+ the file starts with ``callgrind.out``. This matches the default file
+ filtering done by KCacheGrind's Open Dialog. (Ian Clatworthy)
+
+* Fix ``bzr update`` to avoid an unnecessary
+ ``branch.get_master_branch`` call, which avoids 1 extra connection
+ to the remote server. (Partial fix for #128076, John Arbash Meinel)
+
+* Log errors from the smart server in the trace file, to make debugging
+ test failures (and live failures!) easier. (Andrew Bennetts)
+
+* The HTML version of the man page has been superceded by a more
+ comprehensive manual called the Bazaar User Reference. This manual
+ is completed generated from the online help topics. As part of this
+ change, limited reStructuredText is now explicitly supported in help
+ topics and command help with 'unnatural' markup being removed prior
+ to display by the online help or inclusion in the man page.
+ (Ian Clatworthy)
+
+* HTML documentation now use files extension ``*.html``
+ (Alexander Belchenko)
+
+* The cache of ignore definitions is now cleared in WorkingTree.unlock()
+ so that changes to .bzrignore aren't missed. (#129694, Daniel Watkins)
+
+* ``bzr selftest --strict`` fails if there are any missing features or
+ expected test failures. (Daniel Watkins, #111914)
+
+* Link to registration survey added to README. (Ian Clatworthy)
+
+* Windows standalone installer show link to registration survey
+ when installation finished. (Alexander Belchenko)
+
+Library API Breaks
+******************
+
+* Deprecated dictionary ``bzrlib.option.SHORT_OPTIONS`` removed.
+ Options are now required to provide a help string and it must
+ comply with the style guide by being one or more sentences with an
+ initial capital and final period. (Martin Pool)
+
+* KnitIndex.get_parents now returns tuples. (Robert Collins)
+
+* Ancient unused ``Repository.text_store`` attribute has been removed.
+ (Robert Collins)
+
+* The ``bzrlib.pack`` interface has changed to use tuples of bytestrings
+ rather than just bytestrings, making it easier to represent multiple
+ element names. As this interface was not used by any internal facilities
+ since it was introduced in 0.18 no API compatibility is being preserved.
+ The serialised form of these packs is identical with 0.18 when a single
+ element tuple is in use. (Robert Collins)
+
+Internals
+*********
+
+* merge now uses ``iter_changes`` to calculate changes, which makes room for
+ future performance increases. It is also more consistent with other
+ operations that perform comparisons, and reduces reliance on
+ Tree.inventory. (Aaron Bentley)
+
+* Refactoring of transport classes connected to a remote server.
+ ConnectedTransport is a new class that serves as a basis for all
+ transports needing to connect to a remote server. transport.split_url
+ have been deprecated, use the static method on the object instead. URL
+ tests have been refactored too.
+ (Vincent Ladeuil)
+
+* Better connection sharing for ConnectedTransport objects.
+ transport.get_transport() now accepts a 'possible_transports' parameter.
+ If a newly requested transport can share a connection with one of the
+ list, it will.
+ (Vincent Ladeuil)
+
+* Most functions now accept ``bzrlib.revision.NULL_REVISION`` to indicate
+ the null revision, and consider using ``None`` for this purpose
+ deprecated. (Aaron Bentley)
+
+* New ``index`` module with abstract index functionality. This will be
+ used during the planned changes in the repository layer. Currently the
+ index layer provides a graph aware immutable index, a builder for the
+ same index type to allow creating them, and finally a composer for
+ such indices to allow the use of many indices in a single query. The
+ index performance is not optimised, however the API is stable to allow
+ development on top of the index. (Robert Collins)
+
+* ``bzrlib.dirstate.cmp_by_dirs`` can be used to compare two paths by
+ their directory sections. This is equivalent to comparing
+ ``path.split('/')``, only without having to split the paths.
+ This has a Pyrex implementation available.
+ (John Arbash Meinel)
+
+* New transport decorator 'unlistable+' which disables the list_dir
+ functionality for testing.
+
+* Deprecated ``change_entry`` in transform.py. (Ian Clatworthy)
+
+* RevisionTree.get_weave is now deprecated. Tree.plan_merge is now used
+ for performing annotate-merge. (Aaron Bentley)
+
+* New EmailMessage class to create email messages. (Adeodato Simó)
+
+* Unused functions on the private interface KnitIndex have been removed.
+ (Robert Collins)
+
+* New ``knit.KnitGraphIndex`` which provides a ``KnitIndex`` layered on top
+ of a ``index.GraphIndex``. (Robert Collins)
+
+* New ``knit.KnitVersionedFile.iter_parents`` method that allows querying
+ the parents of many knit nodes at once, reducing round trips to the
+ underlying index. (Robert Collins)
+
+* Graph now has an is_ancestor method, various bits use it.
+ (Aaron Bentley)
+
+* The ``-Dhpss`` flag now includes timing information. As well as
+ logging when a new connection is opened. (John Arbash Meinel)
+
+* ``bzrlib.pack.ContainerWriter`` now returns an offset, length tuple to
+ callers when inserting data, allowing generation of readv style access
+ during pack creation, without needing a separate pass across the output
+ pack to gather such details. (Robert Collins)
+
+* ``bzrlib.pack.make_readv_reader`` allows readv based access to pack
+ files that are stored on a transport. (Robert Collins)
+
+* New ``Repository.has_same_location`` method that reports if two
+ repository objects refer to the same repository (although with some risk
+ of false negatives). (Andrew Bennetts)
+
+* InterTree.compare now passes require_versioned on correctly.
+ (Marius Kruger)
+
+* New methods on Repository - ``start_write_group``,
+ ``commit_write_group``, ``abort_write_group`` and ``is_in_write_group`` -
+ which provide a clean hook point for transactional Repositories - ones
+ where all the data for a fetch or commit needs to be made atomically
+ available in one step. This allows the write lock to remain while making
+ a series of data insertions. (e.g. data conversion). (Robert Collins)
+
+* In ``bzrlib.knit`` the internal interface has been altered to use
+ 3-tuples (index, pos, length) rather than two-tuples (pos, length) to
+ describe where data in a knit is, allowing knits to be split into
+ many files. (Robert Collins)
+
+* ``bzrlib.knit._KnitData`` split into cache management and physical access
+ with two access classes - ``_PackAccess`` and ``_KnitAccess`` defined.
+ The former provides access into a .pack file, and the latter provides the
+ current production repository form of .knit files. (Robert Collins)
+
+Testing
+*******
+
+* Remove selftest ``--clean-output``, ``--numbered-dirs`` and
+ ``--keep-output`` options, which are obsolete now that tests
+ are done within directories in $TMPDIR. (Martin Pool)
+
+* The SSH_AUTH_SOCK environment variable is now reset to avoid
+ interaction with any running SSH agents. (Jelmer Vernooij, #125955)
+
+* run_bzr_subprocess handles parameters the same way as run_bzr:
+ either a string or a list of strings should be passed as the first
+ parameter. Varargs-style parameters are deprecated. (Aaron Bentley)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
+
diff --git a/doc/en/release-notes/bzr-0.91.txt b/doc/en/release-notes/bzr-0.91.txt
new file mode 100644
index 0000000..11892a8
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.91.txt
@@ -0,0 +1,372 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.91
+########
+
+:Released: 2007-09-26
+
+Bug Fixes
+*********
+
+* Print a warning instead of aborting the ``python setup.py install``
+ process if building of a C extension is not possible.
+ (Lukáš Lalinský, Alexander Belchenko)
+
+* Fix commit ordering in corner case (Aaron Bentley, #94975)
+
+* Fix ''bzr info bzr://host/'' and other operations on ''bzr://' URLs with
+ an implicit port. We were incorrectly raising PathNotChild due to
+ inconsistent treatment of the ''_port'' attribute on the Transport object.
+ (Andrew Bennetts, #133965)
+
+* Make RemoteRepository.sprout cope gracefully with servers that don't
+ support the ``Repository.tarball`` request.
+ (Andrew Bennetts)
+
+
+bzr 0.91rc2
+###########
+
+:Released: 2007-09-11
+
+* Replaced incorrect tarball for previous release; a debug statement was left
+ in bzrlib/remote.py.
+
+
+bzr 0.91rc1
+###########
+
+:Released: 2007-09-11
+
+Changes
+*******
+
+* The default branch and repository format has changed to
+ ``dirstate-tags``, so tag commands are active by default.
+ This format is compatible with Bazaar 0.15 and later.
+ This incidentally fixes bug #126141.
+ (Martin Pool)
+
+* ``--quiet`` or ``-q`` is no longer a global option. If present, it
+ must now appear after the command name. Scripts doing things like
+ ``bzr -q missing`` need to be rewritten as ``bzr missing -q``.
+ (Ian Clatworthy)
+
+Features
+********
+
+* New option ``--author`` in ``bzr commit`` to specify the author of the
+ change, if it's different from the committer. ``bzr log`` and
+ ``bzr annotate`` display the author instead of the committer.
+ (Lukáš Lalinský)
+
+* In addition to global options and command specific options, a set of
+ standard options are now supported. Standard options are legal for
+ all commands. The initial set of standard options are:
+
+ * ``--help`` or ``-h`` - display help message
+ * ``--verbose`` or ``-v`` - display additional information
+ * ``--quiet`` or ``-q`` - only output warnings and errors.
+
+ Unlike global options, standard options can be used in aliases and
+ may have command-specific help. (Ian Clatworthy)
+
+* Verbosity level processing has now been unified. If ``--verbose``
+ or ``-v`` is specified on the command line multiple times, the
+ verbosity level is made positive the first time then increased.
+ If ``--quiet`` or ``-q`` is specified on the command line
+ multiple times, the verbosity level is made negative the first
+ time then decreased. To get the default verbosity level of zero,
+ either specify none of the above , ``--no-verbose`` or ``--no-quiet``.
+ Note that most commands currently ignore the magnitude of the
+ verbosity level but do respect *quiet vs normal vs verbose* when
+ generating output. (Ian Clatworthy)
+
+* ``Branch.hooks`` now supports ``pre_commit`` hook. The hook's signature
+ is documented in BranchHooks constructor. (Nam T. Nguyen, #102747)
+
+* New ``Repository.stream_knit_data_for_revisions`` request added to the
+ network protocol for greatly reduced roundtrips when retrieving a set of
+ revisions. (Andrew Bennetts)
+
+Bug Fixes
+*********
+
+* ``bzr plugins`` now lists the version number for each plugin in square
+ brackets after the path. (Robert Collins, #125421)
+
+* Pushing, pulling and branching branches with subtree references was not
+ copying the subtree weave, preventing the file graph from being accessed
+ and causing errors in commits in clones. (Robert Collins)
+
+* Suppress warning "integer argument expected, got float" from Paramiko,
+ which sometimes caused false test failures. (Martin Pool)
+
+* Fix bug in bundle 4 that could cause attempts to write data to wrong
+ versionedfile. (Aaron Bentley)
+
+* Diffs generated using "diff -p" no longer break the patch parser.
+ (Aaron Bentley)
+
+* get_transport treats an empty possible_transports list the same as a non-
+ empty one. (Aaron Bentley)
+
+* patch verification for merge directives is reactivated, and works with
+ CRLF and CR files. (Aaron Bentley)
+
+* Accept ..\ as a path in revision specifiers. This fixes for example
+ "-r branch:..\other-branch" on Windows. (Lukáš Lalinský)
+
+* ``BZR_PLUGIN_PATH`` may now contain trailing slashes.
+ (Blake Winton, #129299)
+
+* man page no longer lists hidden options (#131667, Aaron Bentley)
+
+* ``uncommit --help`` now explains the -r option adequately. (Daniel
+ Watkins, #106726)
+
+* Error messages are now better formatted with parameters (such as
+ filenames) quoted when necessary. This avoids confusion when directory
+ names ending in a '.' at the end of messages were confused with a
+ full stop that may or not have been there. (Daniel Watkins, #129791)
+
+* Fix ``status FILE -r X..Y``. (Lukáš Lalinský)
+
+* If a particular command is an alias, ``help`` will show the alias
+ instead of claiming there is no help for said alias. (Daniel Watkins,
+ #133548)
+
+* TreeTransform-based operations, like pull, merge, revert, and branch,
+ now roll back if they encounter an error. (Aaron Bentley, #67699)
+
+* ``bzr commit`` now exits cleanly if a character unsupported by the
+ current encoding is used in the commit message. (Daniel Watkins,
+ #116143)
+
+* bzr send uses default values for ranges when only half of an elipsis
+ is specified ("-r..5" or "-r5.."). (#61685, Aaron Bentley)
+
+* Avoid trouble when Windows SSH calls itself 'plink' but no plink
+ binary is present. (Martin Albisetti, #107155)
+
+* ``bzr remove`` should remove clean subtrees. Now it will remove (without
+ needing ``--force``) subtrees that contain no files with text changes or
+ modified files. With ``--force`` it removes the subtree regardless of
+ text changes or unknown files. Directories with renames in or out (but
+ not changed otherwise) will now be removed without needing ``--force``.
+ Unknown ignored files will be deleted without needing ``--force``.
+ (Marius Kruger, #111665)
+
+* When two plugins conflict, the source of both the losing and now the
+ winning definition is shown. (Konstantin Mikhaylov, #5454)
+
+* When committing to a branch, the location being committed to is
+ displayed. (Daniel Watkins, #52479)
+
+* ``bzr --version`` takes care about encoding of stdout, especially
+ when output is redirected. (Alexander Belchenko, #131100)
+
+* Prompt for an FTP password if none is provided.
+ (Vincent Ladeuil, #137044)
+
+* Reuse bound branch associated transport to avoid multiple
+ connections.
+ (Vincent Ladeuil, #128076, #131396)
+
+* Overwrite conflicting tags by ``push`` and ``pull`` if the
+ ``--overwrite`` option is specified. (Lukáš Lalinský, #93947)
+
+* In checkouts, tags are copied into the master branch when created,
+ changed or deleted, and are copied into the checkout when it is
+ updated. (Martin Pool, #93856, #93860)
+
+* Print a warning instead of aborting the ``python setup.py install``
+ process if building of a C extension is not possible.
+ (Lukáš Lalinský, Alexander Belchenko)
+
+Improvements
+************
+
+* Add the option "--show-diff" to the commit command in order to display
+ the diff during the commit log creation. (Goffredo Baroncelli)
+
+* ``pull`` and ``merge`` are much faster at installing bundle format 4.
+ (Aaron Bentley)
+
+* ``pull -v`` no longer includes deltas, making it much faster.
+ (Aaron Bentley)
+
+* ``send`` now sends the directive as an attachment by default.
+ (Aaron Bentley, Lukáš Lalinský, Alexander Belchenko)
+
+* Documentation updates (Martin Albisetti)
+
+* Help on debug flags is now included in ``help global-options``.
+ (Daniel Watkins, #124853)
+
+* Parameters passed on the command line are checked to ensure they are
+ supported by the encoding in use. (Daniel Watkins)
+
+* The compression used within the bzr repository has changed from zlib
+ level 9 to the zlib default level. This improves commit performance with
+ only a small increase in space used (and in some cases a reduction in
+ space). (Robert Collins)
+
+* Initial commit no longer SHAs files twice and now reuses the path
+ rather than looking it up again, making it faster.
+ (Ian Clatworthy)
+
+* New option ``-c``/``--change`` for ``diff`` and ``status`` to show
+ changes in one revision. (Lukáš Lalinský)
+
+* If versioned files match a given ignore pattern, a warning is now
+ given. (Daniel Watkins, #48623)
+
+* ``bzr status`` now has -S as a short name for --short and -V as a
+ short name for --versioned. These have been added to assist users
+ migrating from Subversion: ``bzr status -SV`` is now like
+ ``svn status -q``. (Daniel Watkins, #115990)
+
+* Added C implementation of ``PatienceSequenceMatcher``, which is about
+ 10x faster than the Python version. This speeds up commands that
+ need file diffing, such as ``bzr commit`` or ``bzr diff``.
+ (Lukáš Lalinský)
+
+* HACKING has been extended with a large section on core developer tasks.
+ (Ian Clatworthy)
+
+* Add ``branches`` and ``standalone-trees`` as online help topics and
+ include them as Concepts within the User Reference.
+ (Paul Moore, Ian Clatworthy)
+
+* ``check`` can detect versionedfile parent references that are
+ inconsistent with revision and inventory info, and ``reconcile`` can fix
+ them. These faulty references were generated by 0.8-era releases,
+ so repositories which were manipulated by old bzrs should be
+ checked, and possibly reconciled ASAP. (Aaron Bentley, Andrew Bennetts)
+
+API Breaks
+**********
+
+* ``Branch.append_revision`` is removed altogether; please use
+ ``Branch.set_last_revision_info`` instead. (Martin Pool)
+
+* CommitBuilder now advertises itself as requiring the root entry to be
+ supplied. This only affects foreign repository implementations which reuse
+ CommitBuilder directly and have changed record_entry_contents to require
+ that the root not be supplied. This should be precisely zero plugins
+ affected. (Robert Collins)
+
+* The ``add_lines`` methods on ``VersionedFile`` implementations has changed
+ its return value to include the sha1 and length of the inserted text. This
+ allows the avoidance of double-sha1 calculations during commit.
+ (Robert Collins)
+
+* ``Transport.should_cache`` has been removed. It was not called in the
+ previous release. (Martin Pool)
+
+Testing
+*******
+
+* Tests may now raise TestNotApplicable to indicate they shouldn't be
+ run in a particular scenario. (Martin Pool)
+
+* New function multiply_tests_from_modules to give a simpler interface
+ to test parameterization. (Martin Pool, Robert Collins)
+
+* ``Transport.should_cache`` has been removed. It was not called in the
+ previous release. (Martin Pool)
+
+* NULL_REVISION is returned to indicate the null revision, not None.
+ (Aaron Bentley)
+
+* Use UTF-8 encoded StringIO for log tests to avoid failures on
+ non-ASCII committer names. (Lukáš Lalinský)
+
+Internals
+*********
+
+* ``bzrlib.plugin.all_plugins`` has been deprecated in favour of
+ ``bzrlib.plugin.plugins()`` which returns PlugIn objects that provide
+ useful functionality for determining the path of a plugin, its tests, and
+ its version information. (Robert Collins)
+
+* Add the option user_encoding to the function 'show_diff_trees()'
+ in order to move the user encoding at the UI level. (Goffredo Baroncelli)
+
+* Add the function make_commit_message_template_encoded() and the function
+ edit_commit_message_encoded() which handle encoded strings.
+ This is done in order to mix the commit messages (which is a unicode
+ string), and the diff which is a raw string. (Goffredo Baroncelli)
+
+* CommitBuilder now defaults to using add_lines_with_ghosts, reducing
+ overhead on non-weave repositories which don't require all parents to be
+ present. (Robert Collins)
+
+* Deprecated method ``find_previous_heads`` on
+ ``bzrlib.inventory.InventoryEntry``. This has been superseded by the use
+ of ``parent_candidates`` and a separate heads check via the repository
+ API. (Robert Collins)
+
+* New trace function ``mutter_callsite`` will print out a subset of the
+ stack to the log, which can be useful for gathering debug details.
+ (Robert Collins)
+
+* ``bzrlib.pack.ContainerWriter`` now tracks how many records have been
+ added via a public attribute records_written. (Robert Collins)
+
+* New method ``bzrlib.transport.Transport.get_recommended_page_size``.
+ This provides a hint to users of transports as to the reasonable
+ minimum data to read. In principle this can take latency and
+ bandwidth into account on a per-connection basis, but for now it
+ just has hard coded values based on the URL. (E.g., http:// has a large
+ page size, file:// has a small one.) (Robert Collins)
+
+* New method on ``bzrlib.transport.Transport`` ``open_write_stream`` allows
+ incremental addition of data to a file without requiring that all the
+ data be buffered in memory. (Robert Collins)
+
+* New methods on ``bzrlib.knit.KnitVersionedFile``:
+ ``get_data_stream(versions)``, ``insert_data_stream(stream)`` and
+ ``get_format_signature()``. These provide some infrastructure for
+ efficiently streaming the knit data for a set of versions over the smart
+ protocol.
+
+* Knits with no annotation cache still produce correct annotations.
+ (Aaron Bentley)
+
+* Three new methods have been added to ``bzrlib.trace``:
+ ``set_verbosity_level``, ``get_verbosity_level`` and ``is_verbose``.
+ ``set_verbosity_level`` expects a numeric value: negative for quiet,
+ zero for normal, positive for verbose. The size of the number can be
+ used to determine just how quiet or verbose the application should be.
+ The existing ``be_quiet`` and ``is_quiet`` routines have been
+ integrated into this new scheme. (Ian Clatworthy)
+
+* Options can now be delcared with a ``custom_callback`` parameter. If
+ set, this routine is called after the option is processed. This feature
+ is now used by the standard options ``verbose`` and ``quiet`` so that
+ setting one implicitly resets the other. (Ian Clatworthy)
+
+* Rather than declaring a new option from scratch in order to provide
+ custom help, a centrally registered option can be decorated using the
+ new ``bzrlib.Option.custom_help`` routine. In particular, this routine
+ is useful when declaring better help for the ``verbose`` and ``quiet``
+ standard options as the base definition of these is now more complex
+ than before thanks to their use of a custom callback. (Ian Clatworthy)
+
+* Tree._iter_changes(specific_file=[]) now iterates through no files,
+ instead of iterating through all files. None is used to iterate through
+ all files. (Aaron Bentley)
+
+* WorkingTree.revert() now accepts None to revert all files. The use of
+ [] to revert all files is deprecated. (Aaron Bentley)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-0.92.txt b/doc/en/release-notes/bzr-0.92.txt
new file mode 100644
index 0000000..f198e28
--- /dev/null
+++ b/doc/en/release-notes/bzr-0.92.txt
@@ -0,0 +1,342 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 0.92
+########
+
+:Released: 2007-11-05
+
+Changes
+*******
+
+ * New uninstaller on Win32. (Alexander Belchenko)
+
+
+bzr 0.92rc1
+###########
+
+:Released: 2007-10-29
+
+Changes
+*******
+
+* ``bzr`` now returns exit code 4 if an internal error occurred, and
+ 3 if a normal error occurred. (Martin Pool)
+
+* ``pull``, ``merge`` and ``push`` will no longer silently correct some
+ repository index errors that occured as a result of the Weave disk format.
+ Instead the ``reconcile`` command needs to be run to correct those
+ problems if they exist (and it has been able to fix most such problems
+ since bzr 0.8). Some new problems have been identified during this release
+ and you should run ``bzr check`` once on every repository to see if you
+ need to reconcile. If you cannot ``pull`` or ``merge`` from a remote
+ repository due to mismatched parent errors - a symptom of index errors -
+ you should simply take a full copy of that remote repository to a clean
+ directory outside any local repositories, then run reconcile on it, and
+ finally pull from it locally. (And naturally email the repositories owner
+ to ask them to upgrade and run reconcile).
+ (Robert Collins)
+
+Features
+********
+
+* New ``knitpack-experimental`` repository format. This is interoperable with
+ the ``dirstate-tags`` format but uses a smarter storage design that greatly
+ speeds up many operations, both local and remote. This new format can be
+ used as an option to the ``init``, ``init-repository`` and ``upgrade``
+ commands. (Robert Collins)
+
+* For users of bzr-svn (and those testing the prototype subtree support) that
+ wish to try packs, a new ``knitpack-subtree-experimental`` format has also
+ been added. This is interoperable with the ``dirstate-subtrees`` format.
+ (Robert Collins)
+
+* New ``reconfigure`` command. (Aaron Bentley)
+
+* New ``revert --forget-merges`` command, which removes the record of a pending
+ merge without affecting the working tree contents. (Martin Pool)
+
+* New ``bzr_remote_path`` configuration variable allows finer control of
+ remote bzr locations than BZR_REMOTE_PATH environment variable.
+ (Aaron Bentley)
+
+* New ``launchpad-login`` command to tell Bazaar your Launchpad
+ user ID. This can then be used by other functions of the
+ Launchpad plugin. (James Henstridge)
+
+Performance
+***********
+
+* Commit in quiet mode is now slightly faster as the information to
+ output is no longer calculated. (Ian Clatworthy)
+
+* Commit no longer checks for new text keys during insertion when the
+ revision id was deterministically unique. (Robert Collins)
+
+* Committing a change which is not a merge and does not change the number of
+ files in the tree is faster by utilising the data about whether files are
+ changed to determine if the tree is unchanged rather than recalculating
+ it at the end of the commit process. (Robert Collins)
+
+* Inventory serialisation no longer double-sha's the content.
+ (Robert Collins)
+
+* Knit text reconstruction now avoids making copies of the lines list for
+ interim texts when building a single text. The new ``apply_delta`` method
+ on ``KnitContent`` aids this by allowing modification of the revision id
+ such objects represent. (Robert Collins)
+
+* Pack indices are now partially parsed for specific key lookup using a
+ bisection approach. (Robert Collins)
+
+* Partial commits are now approximately 40% faster by walking over the
+ unselected current tree more efficiently. (Robert Collins)
+
+* XML inventory serialisation takes 20% less time while being stricter about
+ the contents. (Robert Collins)
+
+* Graph ``heads()`` queries have been fixed to no longer access all history
+ unnecessarily. (Robert Collins)
+
+Improvements
+************
+
+* ``bzr+https://`` smart server across https now supported.
+ (John Ferlito, Martin Pool, #128456)
+
+* Mutt is now a supported mail client; set ``mail_client=mutt`` in your
+ bazaar.conf and ``send`` will use mutt. (Keir Mierle)
+
+* New option ``-c``/``--change`` for ``merge`` command for cherrypicking
+ changes from one revision. (Alexander Belchenko, #141368)
+
+* Show encodings, locale and list of plugins in the traceback message.
+ (Martin Pool, #63894)
+
+* Experimental directory formats can now be marked with
+ ``experimental = True`` during registration. (Ian Clatworthy)
+
+Documentation
+*************
+
+* New *Bazaar in Five Minutes* guide. (Matthew Revell)
+
+* The hooks reference documentation is now converted to html as expected.
+ (Ian Clatworthy)
+
+Bug Fixes
+*********
+
+* Connection error reporting for the smart server has been fixed to
+ display a user friendly message instead of a traceback.
+ (Ian Clatworthy, #115601)
+
+* Make sure to use ``O_BINARY`` when opening files to check their
+ sha1sum. (Alexander Belchenko, John Arbash Meinel, #153493)
+
+* Fix a problem with Win32 handling of the executable bit.
+ (John Arbash Meinel, #149113)
+
+* ``bzr+ssh://`` and ``sftp://`` URLs that do not specify ports explicitly
+ no longer assume that means port 22. This allows people using OpenSSH to
+ override the default port in their ``~/.ssh/config`` if they wish. This
+ fixes a bug introduced in bzr 0.91. (Andrew Bennetts, #146715)
+
+* Commands reporting exceptions can now be profiled and still have their
+ data correctly dumped to a file. For example, a ``bzr commit`` with
+ no changes still reports the operation as pointless but doing so no
+ longer throws away the profiling data if this command is run with
+ ``--lsprof-file callgrind.out.ci`` say. (Ian Clatworthy)
+
+* Fallback to FTP when paramiko is not installed and SFTP can't be used for
+ ``tests/commands`` so that the test suite is still usable without
+ paramiko.
+ (Vincent Ladeuil, #59150)
+
+* Fix commit ordering in corner case. (Aaron Bentley, #94975)
+
+* Fix long standing bug in partial commit when there are renames
+ left in tree. (Robert Collins, #140419)
+
+* Fix selftest semi-random noise during HTTP related tests.
+ (Vincent Ladeuil, #140614)
+
+* Fix typo in ftp.py making the reconnection fail on temporary errors.
+ (Vincent Ladeuil, #154259)
+
+* Fix failing test by comparing real paths to cover the case where the TMPDIR
+ contains a symbolic link.
+ (Vincent Ladeuil, #141382).
+
+* Fix log against smart server branches that don't support tags.
+ (James Westby, #140615)
+
+* Fix pycurl HTTP implementation by defining error codes from
+ pycurl instead of relying on an old curl definition.
+ (Vincent Ladeuil, #147530)
+
+* Fix 'unprintable error' message when displaying BzrCheckError and
+ some other exceptions on Python 2.5.
+ (Martin Pool, #144633)
+
+* Fix ``Inventory.copy()`` and add test for it. (Jelmer Vernooij)
+
+* Handles default value for ListOption in cmd_commit.
+ (Vincent Ladeuil, #140432)
+
+* HttpServer and FtpServer need to be closed properly or a listening socket
+ will remain opened.
+ (Vincent Ladeuil, #140055)
+
+* Monitor the .bzr directory created in the top level test
+ directory to detect leaking tests.
+ (Vincent Ladeuil, #147986)
+
+* The basename, not the full path, is now used when checking whether
+ the profiling dump file begins with ``callgrind.out`` or not. This
+ fixes a bug reported by Aaron Bentley on IRC. (Ian Clatworthy)
+
+* Trivial fix for invoking command ``reconfigure`` without arguments.
+ (Rob Weir, #141629)
+
+* ``WorkingTree.rename_one`` will now raise an error if normalisation of the
+ new path causes bzr to be unable to access the file. (Robert Collins)
+
+* Correctly detect a NoSuchFile when using a filezilla server. (Gary van der
+ Merwe)
+
+API Breaks
+**********
+
+* ``bzrlib.index.GraphIndex`` now requires a size parameter to the
+ constructor, for enabling bisection searches. (Robert Collins)
+
+* ``CommitBuilder.record_entry_contents`` now requires the root entry of a
+ tree be supplied to it, previously failing to do so would trigger a
+ deprecation warning. (Robert Collins)
+
+* ``KnitVersionedFile.add*`` will no longer cache added records even when
+ enable_cache() has been called - the caching feature is now exclusively for
+ reading existing data. (Robert Collins)
+
+* ``ReadOnlyLockError`` is deprecated; ``LockFailed`` is usually more
+ appropriate. (Martin Pool)
+
+* Removed ``bzrlib.transport.TransportLogger`` - please see the new
+ ``trace+`` transport instead. (Robert Collins)
+
+* Removed previously deprecated varargs interface to ``TestCase.run_bzr`` and
+ deprecated methods ``TestCase.capture`` and ``TestCase.run_bzr_captured``.
+ (Martin Pool)
+
+* Removed previous deprecated ``basis_knit`` parameter to the
+ ``KnitVersionedFile`` constructor. (Robert Collins)
+
+* Special purpose method ``TestCase.run_bzr_decode`` is moved to the test_non_ascii
+ class that needs it.
+ (Martin Pool)
+
+* The class ``bzrlib.repofmt.knitrepo.KnitRepository3`` has been folded into
+ ``KnitRepository`` by parameters to the constructor. (Robert Collins)
+
+* The ``VersionedFile`` interface now allows content checks to be bypassed
+ by supplying check_content=False. This saves nearly 30% of the minimum
+ cost to store a version of a file. (Robert Collins)
+
+* Tree's with bad state such as files with no length or sha will no longer
+ be silently accepted by the repository XML serialiser. To serialise
+ inventories without such data, pass working=True to write_inventory.
+ (Robert Collins)
+
+* ``VersionedFile.fix_parents`` has been removed as a harmful API.
+ ``VersionedFile.join`` will no longer accept different parents on either
+ side of a join - it will either ignore them, or error, depending on the
+ implementation. See notes when upgrading for more information.
+ (Robert Collins)
+
+Internals
+*********
+
+* ``bzrlib.transport.Transport.put_file`` now returns the number of bytes
+ put by the method call, to allow avoiding stat-after-write or
+ housekeeping in callers. (Robert Collins)
+
+* ``bzrlib.xml_serializer.Serializer`` is now responsible for checking that
+ mandatory attributes are present on serialisation and deserialisation.
+ This fixes some holes in API usage and allows better separation between
+ physical storage and object serialisation. (Robert Collins)
+
+* New class ``bzrlib.errors.InternalBzrError`` which is just a convenient
+ shorthand for deriving from BzrError and setting internal_error = True.
+ (Robert Collins)
+
+* New method ``bzrlib.mutabletree.update_to_one_parent_via_delta`` for
+ moving the state of a parent tree to a new version via a delta rather than
+ a complete replacement tree. (Robert Collins)
+
+* New method ``bzrlib.osutils.minimum_path_selection`` useful for removing
+ duplication from user input, when a user mentions both a path and an item
+ contained within that path. (Robert Collins)
+
+* New method ``bzrlib.repository.Repository.is_write_locked`` useful for
+ determining if a repository is write locked. (Robert Collins)
+
+* New method on ``bzrlib.tree.Tree`` ``path_content_summary`` provides a
+ tuple containing the key information about a path for commit processing
+ to complete. (Robert Collins)
+
+* New method on XML serialisers, write_inventory_to_lines, which matches the
+ API used by knits for adding content. (Robert Collins)
+
+* New module ``bzrlib.bisect_multi`` with generic multiple-bisection-at-once
+ logic, currently only available for byte-based lookup
+ (``bisect_multi_bytes``). (Robert Collins)
+
+* New helper ``bzrlib.tuned_gzip.bytes_to_gzip`` which takes a byte string
+ and returns a gzipped version of the same. This is used to avoid a bunch
+ of api friction during adding of knit hunks. (Robert Collins)
+
+* New parameter on ``bzrlib.transport.Transport.readv``
+ ``adjust_for_latency`` which changes readv from returning strictly the
+ requested data to inserted return larger ranges and in forward read order
+ to reduce the effect of network latency. (Robert Collins)
+
+* New parameter yield_parents on ``Inventory.iter_entries_by_dir`` which
+ causes the parents of a selected id to be returned recursively, so all the
+ paths from the root down to each element of selected_file_ids are
+ returned. (Robert Collins)
+
+* Knit joining has been enhanced to support plain to annotated conversion
+ and annotated to plain conversion. (Ian Clatworthy)
+
+* The CommitBuilder method ``record_entry_contents`` now returns summary
+ information about the effect of the commit on the repository. This tuple
+ contains an inventory delta item if the entry changed from the basis, and a
+ boolean indicating whether a new file graph node was recorded.
+ (Robert Collins)
+
+* The python path used in the Makefile can now be overridden.
+ (Andrew Bennetts, Ian Clatworthy)
+
+Testing
+*******
+
+* New transport implementation ``trace+`` which is useful for testing,
+ logging activity taken to its _activity attribute. (Robert Collins)
+
+* When running bzr commands within the test suite, internal exceptions are
+ not caught and reported in the usual way, but rather allowed to propagate
+ up and be visible to the test suite. A new API ``run_bzr_catch_user_errors``
+ makes this behavior available to other users.
+ (Martin Pool)
+
+* New method ``TestCase.call_catch_warnings`` for testing methods that
+ raises a Python warning. (Martin Pool)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.0.txt b/doc/en/release-notes/bzr-1.0.txt
new file mode 100644
index 0000000..e6d724d
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.0.txt
@@ -0,0 +1,429 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.0
+#######
+
+:Released: 2007-12-14
+
+Documentation
+*************
+
+* More improvements and fixes to the User Guide. (Ian Clatworthy)
+
+* Add information on cherrypicking/rebasing to the User Guide.
+ (Ian Clatworthy)
+
+* Improve bug tracker integration documentation. (Ian Clatworthy)
+
+* Minor edits to ``Bazaar in five minutes`` from David Roberts and
+ to the rebasing section of the User Guide from Aaron Bentley.
+ (Ian Clatworthy)
+
+
+bzr 1.0rc3
+##########
+
+:Released: 2007-12-11
+
+Changes
+*******
+
+* If a traceback occurs, users are now asked to report the bug
+ through Launchpad (https://bugs.launchpad.net/bzr/), rather than
+ by mail to the mailing list.
+ (Martin Pool)
+
+Bugfixes
+********
+
+* Fix Makefile rules for doc generation. (Ian Clatworthy, #175207)
+
+* Give more feedback during long HTTP downloads by making readv deliver data
+ as it arrives for urllib, and issue more requests for pycurl. High latency
+ networks are better handled by urllib, the pycurl implementation give more
+ feedback but also incur more latency.
+ (Vincent Ladeuil, #173010)
+
+* Implement _make_parents_provider on RemoteRepository, allowing generating
+ bundles against branches on a smart server. (Andrew Bennetts, #147836)
+
+Documentation
+*************
+
+* Improved user guide. (Ian Clatworthy)
+
+* The single-page quick reference guide is now available as a PDF.
+ (Ian Clatworthy)
+
+Internals
+*********
+
+* readv urllib HTTP implementation is now a real iterator above the
+ underlying socket and deliver data as soon as it arrives. 'get' still
+ wraps its output in a StringIO.
+ (Vincent Ladeuil)
+
+
+bzr 1.0rc2
+##########
+
+:Released: 2007-12-07
+
+Improvements
+************
+
+* Added a --coverage option to selftest. (Andrew Bennetts)
+
+* Annotate merge (merge-type=weave) now supports cherrypicking.
+ (Aaron Bentley)
+
+* ``bzr commit`` now doesn't print the revision number twice. (Matt
+ Nordhoff, #172612)
+
+* New configuration option ``bugtracker_<tracker_abbrevation>_url`` to
+ define locations of bug trackers that are not directly supported by
+ bzr or a plugin. The URL will be treated as a template and ``{id}``
+ placeholders will be replaced by specific bug IDs. (Lukáš Lalinský)
+
+* Support logging single merge revisions with short and line log formatters.
+ (Kent Gibson)
+
+* User Guide enhanced with suggested readability improvements from
+ Matt Revell and corrections from John Arbash Meinel. (Ian Clatworthy)
+
+* Quick Start Guide renamed to Quick Start Card, moved down in
+ the catalog, provided in pdf and png format and updated to refer
+ to ``send`` instead of ``bundle``. (Ian Clatworthy, #165080)
+
+* ``switch`` can now be used on heavyweight checkouts as well as
+ lightweight ones. After switching a heavyweight checkout, the
+ local branch is a mirror/cache of the new bound branch and
+ uncommitted changes in the working tree are merged. As a safety
+ check, if there are local commits in a checkout which have not
+ been committed to the previously bound branch, then ``switch``
+ fails unless the ``--force`` option is given. This option is
+ now also required if the branch a lightweight checkout is pointing
+ to has been moved. (Ian Clatworthy)
+
+Internals
+*********
+
+* New -Dhttp debug option reports HTTP connections, requests and responses.
+ (Vincent Ladeuil)
+
+* New -Dmerge debug option, which emits merge plans for merge-type=weave.
+
+Bugfixes
+********
+
+* Better error message when running ``bzr cat`` on a non-existant branch.
+ (Lukáš Lalinský, #133782)
+
+* Catch OSError 17 (file exists) in final phase of tree transform and show
+ filename to user.
+ (Alexander Belchenko, #111758)
+
+* Catch ShortReadvErrors while using pycurl. Also make readv more robust by
+ allowing multiple GET requests to be issued if too many ranges are
+ required.
+ (Vincent Ladeuil, #172701)
+
+* Check for missing basis texts when fetching from packs to packs.
+ (John Arbash Meinel, #165290)
+
+* Fall back to showing e-mail in ``log --short/--line`` if the
+ committer/author has only e-mail. (Lukáš Lalinský, #157026)
+
+API Breaks
+**********
+
+* Deprecate not passing a ``location`` argument to commit reporters'
+ ``started`` methods. (Matt Nordhoff)
+
+
+bzr 1.0rc1
+##########
+
+:Released: 2007-11-30
+
+Notes When Upgrading
+********************
+
+* The default repository format is now ``pack-0.92``. This
+ default is used when creating new repositories with ``init`` and
+ ``init-repo``, and when branching over bzr+ssh or bzr+hpss.
+ (See https://bugs.launchpad.net/bugs/164626)
+
+ This format can be read and written by Bazaar 0.92 and later, and
+ data can be transferred to and from older formats.
+
+ To upgrade, please reconcile your repository (``bzr reconcile``), and then
+ upgrade (``bzr upgrade``).
+
+ ``pack-0.92`` offers substantially better scaling and performance than the
+ previous knits format. Some operations are slower where the code already
+ had bad scaling characteristics under knits, the pack format makes such
+ operations more visible as part of being more scalable overall. We will
+ correct such operations over the coming releases and encourage the filing
+ of bugs on any operation which you observe to be slower in a packs
+ repository. One particular case that we do not intend to fix is pulling
+ data from a pack repository into a knit repository over a high latency
+ link; downgrading such data requires reinsertion of the file texts, and
+ this is a classic space/time tradeoff. The current implementation is
+ conservative on memory usage because we need to support converting data
+ from any tree without problems.
+ (Robert Collins, Martin Pool, #164476)
+
+Changes
+*******
+
+* Disable detection of plink.exe as possible SSH vendor. Plink vendor
+ still available if user selects it explicitly with BZR_SSH environment
+ variable. (Alexander Belchenko, workaround for bug #107593)
+
+* The pack format is now accessible as "pack-0.92", or "pack-0.92-subtree"
+ to enable the subtree functions (for example, for bzr-svn).
+ (Martin Pool)
+
+Features
+********
+
+* New ``authentication.conf`` file holding the password or other credentials
+ for remote servers. This can be used for SSH, SFTP, SMTP and other
+ supported transports.
+ (Vincent Ladeuil)
+
+* New rich-root and rich-root-pack formats, recording the same data about
+ tree roots that's recorded for all other directories.
+ (Aaron Bentley, #164639)
+
+* ``pack-0.92`` repositories can now be reconciled.
+ (Robert Collins, #154173)
+
+* ``switch`` command added for changing the branch a lightweight checkout
+ is associated with and updating the tree to reflect the latest content
+ accordingly. This command was previously part of the BzrTools plug-in.
+ (Ian Clatworthy, Aaron Bentley, David Allouche)
+
+* ``reconfigure`` command can now convert branches, trees, or checkouts to
+ lightweight checkouts. (Aaron Bentley)
+
+Performance
+***********
+
+* Commit updates the state of the working tree via a delta rather than
+ supplying entirely new basis trees. For commit of a single specified file
+ this reduces the wall clock time for commit by roughly a 30%.
+ (Robert Collins, Martin Pool)
+
+* Commit with many automatically found deleted paths no longer performs
+ linear scanning for the children of those paths during inventory
+ iteration. This should fix commit performance blowing out when many such
+ paths occur during commit. (Robert Collins, #156491)
+
+* Fetch with pack repositories will no longer read the entire history graph.
+ (Robert Collins, #88319)
+
+* Revert takes out an appropriate lock when reverting to a basis tree, and
+ does not read the basis inventory twice. (Robert Collins)
+
+* Diff does not require an inventory to be generated on dirstate trees.
+ (Aaron Bentley, #149254)
+
+* New annotate merge (--merge-type=weave) implementation is fast on
+ versionedfiles withough cached annotations, e.g. pack-0.92.
+ (Aaron Bentley)
+
+Improvements
+************
+
+* ``bzr merge`` now warns when it encounters a criss-cross merge.
+ (Aaron Bentley)
+
+* ``bzr send`` now doesn't require the target e-mail address to be
+ specified on the command line if an interactive e-mail client is used.
+ (Lukáš Lalinský)
+
+* ``bzr tags`` now prints the revision number for each tag, instead of
+ the revision id, unless --show-ids is passed. In addition, tags can be
+ sorted chronologically instead of lexicographically with --sort=time.
+ (Adeodato Simó, #120231)
+
+* Windows standalone version of bzr is able to load system-wide plugins from
+ "plugins" subdirectory in installation directory. In addition standalone
+ installer write to the registry (HKLM\SOFTWARE\Bazaar) useful info
+ about paths and bzr version. (Alexander Belchenko, #129298)
+
+Documentation
+*************
+
+Bug Fixes
+*********
+
+* A progress bar has been added for knitpack -> knitpack fetching.
+ (Robert Collins, #157789, #159147)
+
+* Branching from a branch via smart server now preserves the repository
+ format. (Andrew Bennetts, #164626)
+
+* ``commit`` is now able to invoke an external editor in a non-ascii
+ directory. (Daniel Watkins, #84043)
+
+* Catch connection errors for FTP.
+ (Vincent Ladeuil, #164567)
+
+* ``check`` no longer reports spurious unreferenced text versions.
+ (Robert Collins, John A Meinel, #162931, #165071)
+
+* Conflicts are now resolved recursively by ``revert``.
+ (Aaron Bentley, #102739)
+
+* Detect invalid transport reuse attempts by catching invalid URLs.
+ (Vincent Ladeuil, #161819)
+
+* Deleting a file without removing it shows a correct diff, not a traceback.
+ (Aaron Bentley)
+
+* Do no use timeout in HttpServer anymore.
+ (Vincent Ladeuil, #158972).
+
+* Don't catch the exceptions related to the HTTP pipeline status before
+ retrying an HTTP request or some programming errors may be masked.
+ (Vincent Ladeuil, #160012)
+
+* Fix ``bzr rm`` to not delete modified and ignored files.
+ (Lukáš Lalinský, #172598)
+
+* Fix exception when revisionspec contains merge revisons but log
+ formatter doesn't support merge revisions. (Kent Gibson, #148908)
+
+* Fix exception when ScopeReplacer is assigned to before any members have
+ been retrieved. (Aaron Bentley)
+
+* Fix multiple connections during checkout --lightweight.
+ (Vincent Ladeuil, #159150)
+
+* Fix possible error in insert_data_stream when copying between
+ pack repositories over bzr+ssh or bzr+http.
+ KnitVersionedFile.get_data_stream now makes sure that requested
+ compression parents are sent before any delta hunks that depend
+ on them.
+ (Martin Pool, #164637)
+
+* Fix typo in limiting offsets coalescing for HTTP, leading to
+ whole files being downloaded instead of parts.
+ (Vincent Ladeuil, #165061)
+
+* FTP server errors don't error in the error handling code.
+ (Robert Collins, #161240)
+
+* Give a clearer message when a pull fails because the source needs
+ to be reconciled.
+ (Martin Pool, #164443)
+
+* It is clearer when a plugin cannot be loaded because of its name, and a
+ suggestion for an acceptable name is given. (Daniel Watkins, #103023)
+
+* Leave port as None in transport objects if user doesn't
+ specify a port in URLs.
+ (vincent Ladeuil, #150860)
+
+* Make sure Repository.fetch(self) is properly a no-op for all
+ Repository implementations. (John Arbash Meinel, #158333)
+
+* Mark .bzr directories as "hidden" on Windows.
+ (Alexander Belchenko, #71147)
+
+* ``merge --uncommitted`` can now operate on a single file.
+ (Aaron Bentley, Lukáš Lalinský, #136890)
+
+* Obsolete packs are now cleaned up by pack and autopack operations.
+ (Robert Collins, #153789)
+
+* Operations pulling data from a smart server where the underlying
+ repositories are not both annotated/both unannotated will now work.
+ (Robert Collins, #165304).
+
+* Reconcile now shows progress bars. (Robert Collins, #159351)
+
+* ``RemoteBranch`` was not initializing ``self._revision_id_to_revno_map``
+ properly. (John Arbash Meinel, #162486)
+
+* Removing an already-removed file reports the file does not exist. (Daniel
+ Watkins, #152811)
+
+* Rename on Windows is able to change filename case.
+ (Alexander Belchenko, #77740)
+
+* Return error instead of a traceback for ``bzr log -r0``.
+ (Kent Gibson, #133751)
+
+* Return error instead of a traceback when bzr is unable to create
+ symlink on some platforms (e.g. on Windows).
+ (Alexander Belchenko, workaround for #81689)
+
+* Revert doesn't crash when restoring a single file from a deleted
+ directory. (Aaron Bentley)
+
+* Stderr output via logging mechanism now goes through encoded wrapper
+ and no more uses utf-8, but terminal encoding instead. So all unicode
+ strings now should be readable in non-utf-8 terminal.
+ (Alexander Belchenko, #54173)
+
+* The error message when ``move --after`` should be used makes how to do so
+ clearer. (Daniel Watkins, #85237)
+
+* Unicode-safe output from ``bzr info``. The output will be encoded
+ using the terminal encoding and unrepresentable characters will be
+ replaced by '?'. (Lukáš Lalinský, #151844)
+
+* Working trees are no longer created when pushing into a local no-trees
+ repo. (Daniel Watkins, #50582)
+
+* Upgrade util/configobj to version 4.4.0.
+ (Vincent Ladeuil, #151208).
+
+* Wrap medusa FTP test server as an FTPServer feature.
+ (Vincent Ladeuil, #157752)
+
+API Breaks
+**********
+
+* ``osutils.backup_file`` is deprecated. Actually it's not used in bzrlib
+ during very long time. (Alexander Belchenko)
+
+* The return value of
+ ``VersionedFile.iter_lines_added_or_present_in_versions`` has been
+ changed. Previously it was an iterator of lines, now it is an iterator of
+ (line, version_id) tuples. This change has been made to aid reconcile and
+ fetch operations. (Robert Collins)
+
+* ``bzrlib.repository.get_versioned_file_checker`` is now private.
+ (Robert Collins)
+
+* The Repository format registry default has been removed; it was previously
+ obsoleted by the bzrdir format default, which implies a default repository
+ format.
+ (Martin Pool)
+
+Internals
+*********
+
+* Added ``ContainerSerialiser`` and ``ContainerPushParser`` to
+ ``bzrlib.pack``. These classes provide more convenient APIs for generating
+ and parsing containers from streams rather than from files. (Andrew
+ Bennetts)
+
+* New module ``lru_cache`` providing a cache for use by tasks that need
+ semi-random access to large amounts of data. (John A Meinel)
+
+* InventoryEntry.diff is now deprecated. Please use diff.DiffTree instead.
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.1.txt b/doc/en/release-notes/bzr-1.1.txt
new file mode 100644
index 0000000..85dfa72
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.1.txt
@@ -0,0 +1,228 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.1
+#######
+
+:Released: 2008-01-15
+
+(no changes from 1.1rc1)
+
+bzr 1.1rc1
+##########
+
+:Released: 2008-01-05
+
+Changes
+*******
+
+* Dotted revision numbers have been revised. Instead of growing longer with
+ nested branches the branch number just increases. (eg instead of 1.1.1.1.1
+ we now report 1.2.1.) This helps scale long lived branches which have many
+ feature branches merged between them. (John Arbash Meinel)
+
+* The syntax ``bzr diff branch1 branch2`` is no longer supported.
+ Use ``bzr diff branch1 --new branch2`` instead. This change has
+ been made to remove the ambiguity where ``branch2`` is in fact a
+ specific file to diff within ``branch1``.
+
+Features
+********
+
+* New option to use custom template-based formats in ``bzr version-info``.
+ (Lukáš Lalinský)
+
+* diff '--using' allows an external diff tool to be used for files.
+ (Aaron Bentley)
+
+* New "lca" merge-type for fast everyday merging that also supports
+ criss-cross merges. (Aaron Bentley)
+
+Improvements
+************
+
+* ``annotate`` now doesn't require a working tree. (Lukáš Lalinský,
+ #90049)
+
+* ``branch`` and ``checkout`` can now use files from a working tree to
+ to speed up the process. For checkout, this requires the new
+ --files-from flag. (Aaron Bentley)
+
+* ``bzr diff`` now sorts files in alphabetical order. (Aaron Bentley)
+
+* ``bzr diff`` now works on branches without working trees. Tree-less
+ branches can also be compared to each other and to working trees using
+ the new diff options ``--old`` and ``--new``. Diffing between branches,
+ with or without trees, now supports specific file filtering as well.
+ (Ian Clatworthy, #6700)
+
+* ``bzr pack`` now orders revision texts in topological order, with newest
+ at the start of the file, promoting linear reads for ``bzr log`` and the
+ like. This partially fixes #154129. (Robert Collins)
+
+* Merge directives now fetch prerequisites from the target branch if
+ needed. (Aaron Bentley)
+
+* pycurl now handles digest authentication.
+ (Vincent Ladeuil)
+
+* ``reconfigure`` can now convert from repositories. (Aaron Bentley)
+
+* ``-l`` is now a short form for ``--limit`` in ``log``. (Matt Nordhoff)
+
+* ``merge`` now warns when merge directives cause cherrypicks.
+ (Aaron Bentley)
+
+* ``split`` now supported, to enable splitting large trees into smaller
+ pieces. (Aaron Bentley)
+
+Bugfixes
+********
+
+* Avoid AttributeError when unlocking a pack repository when an error occurs.
+ (Martin Pool, #180208)
+
+* Better handle short reads when processing multiple range requests.
+ (Vincent Ladeuil, #179368)
+
+* build_tree acceleration uses the correct path when a file has been moved.
+ (Aaron Bentley)
+
+* ``commit`` now succeeds when a checkout and its master branch share a
+ repository. (Aaron Bentley, #177592)
+
+* Fixed error reporting of unsupported timezone format in
+ ``log --timezone``. (Lukáš Lalinský, #178722)
+
+* Fixed Unicode encoding error in ``ignored`` when the output is
+ redirected to a pipe. (Lukáš Lalinský)
+
+* Fix traceback when sending large response bodies over the smart protocol
+ on Windows. (Andrew Bennetts, #115781)
+
+* Fix ``urlutils.relative_url`` for the case of two ``file:///`` URLs
+ pointed to different logical drives on Windows.
+ (Alexander Belchenko, #90847)
+
+* HTTP test servers are now compatible with the HTTP protocol version 1.1.
+ (Vincent Ladeuil, #175524)
+
+* _KnitParentsProvider.get_parent_map now handles requests for ghosts
+ correctly, instead of erroring or attributing incorrect parents to ghosts.
+ (Aaron Bentley)
+
+* ``merge --weave --uncommitted`` now works. (Aaron Bentley)
+
+* pycurl authentication handling was broken and incomplete. Fix handling of
+ user:pass embedded in the URLs.
+ (Vincent Ladeuil, #177643)
+
+* Files inside non-directories are now handled like other conflict types.
+ (Aaron Bentley, #177390)
+
+* ``reconfigure`` is able to convert trees into lightweight checkouts.
+ (Aaron Bentley)
+
+* Reduce lockdir timeout to 0 when running ``bzr serve``. (Andrew Bennetts,
+ #148087)
+
+* Test that the old ``version_info_format`` functions still work, even
+ though they are deprecated. (John Arbash Meinel, ShenMaq, #177872)
+
+* Transform failures no longer cause ImmortalLimbo errors (Aaron Bentley,
+ #137681)
+
+* ``uncommit`` works even when the commit messages of revisions to be
+ removed use characters not supported in the terminal encoding.
+ (Aaron Bentley)
+
+* When dumb HTTP servers return whole files instead of the requested ranges,
+ read the remaining bytes by chunks to avoid overflowing network buffers.
+ (Vincent Ladeuil, #175886)
+
+Documentation
+*************
+
+* Minor tweaks made to the bug tracker integration documentation.
+ (Ian Clatworthy)
+
+* Reference material has now be moved out of the User Guide and added
+ to the User Reference. The User Reference has gained 4 sections as
+ a result: Authenication Settings, Configuration Settings, Conflicts
+ and Hooks. All help topics are now dumped into text format in the
+ doc/en/user-reference directory for those who like browsing that
+ information in their editor. (Ian Clatworthy)
+
+* *Using Bazaar with Launchpad* tutorial added. (Ian Clatworthy)
+
+Internals
+*********
+
+* find_* methods available for BzrDirs, Branches and WorkingTrees.
+ (Aaron Bentley)
+
+* Help topics can now be loaded from files.
+ (Ian Clatworthy, Alexander Belchenko)
+
+* get_parent_map now always provides tuples as its output. (Aaron Bentley)
+
+* Parent Providers should now implement ``get_parent_map`` returning a
+ dictionary instead of ``get_parents`` returning a list.
+ ``Graph.get_parents`` is now deprecated. (John Arbash Meinel,
+ Robert Collins)
+
+* Patience Diff now supports arbitrary python objects, as long as they
+ support ``hash()``. (John Arbash Meinel)
+
+* Reduce selftest overhead to establish test names by memoization.
+ (Vincent Ladeuil)
+
+API Breaks
+**********
+
+Testing
+*******
+
+* Modules can now customise their tests by defining a ``load_tests``
+ attribute. ``pydoc bzrlib.tests.TestUtil.TestLoader.loadTestsFromModule``
+ for the documentation on this attribute. (Robert Collins)
+
+* New helper function ``bzrlib.tests.condition_id_re`` which helps
+ filter tests based on a regular expression search on the tests id.
+ (Robert Collins)
+
+* New helper function ``bzrlib.tests.condition_isinstance`` which helps
+ filter tests based on class. (Robert Collins)
+
+* New helper function ``bzrlib.tests.exclude_suite_by_condition`` which
+ generalises the ``exclude_suite_by_re`` function. (Robert Collins)
+
+* New helper function ``bzrlib.tests.filter_suite_by_condition`` which
+ generalises the ``filter_suite_by_re`` function. (Robert Collins)
+
+* New helper method ``bzrlib.tests.exclude_tests_by_re`` which gives a new
+ TestSuite that does not contain tests from the input that matched a
+ regular expression. (Robert Collins)
+
+* New helper method ``bzrlib.tests.randomize_suite`` which returns a
+ randomized copy of the input suite. (Robert Collins)
+
+* New helper method ``bzrlib.tests.split_suite_by_re`` which splits a test
+ suite into two according to a regular expression. (Robert Collins)
+
+* Parametrize all HTTP tests for the transport implementations, the HTTP protocol versions (1.0 and 1.1) and the authentication schemes.
+ (Vincent Ladeuil)
+
+* The ``exclude_pattern`` and ``random_order`` parameters to the function
+ ``bzrlib.tests.filter_suite_by_re`` have been deprecated. (Robert Collins)
+
+* The method ``bzrlib.tests.sort_suite_by_re`` has been deprecated. It is
+ replaced by the new helper methods added in this release. (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.10.txt b/doc/en/release-notes/bzr-1.10.txt
new file mode 100644
index 0000000..6352456
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.10.txt
@@ -0,0 +1,160 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.10
+########
+
+:Released: 2008-12-05
+
+Bazaar 1.10 has several performance improvements for copying revisions
+(especially for small updates to large projects). There has also been a
+significant amount of effort in polishing stacked branches. The commands
+``shelve`` and ``unshelve`` have become core commands, with an improved
+implementation.
+
+The only changes versus bzr-1.10rc1 are bugfixes for stacked branches.
+
+bug Fixes
+*********
+
+* Don't set a pack write cache size from RepoFetcher, because the
+ cache is not coherent with reads and causes ShortReadvErrors.
+ This reverses the change that fixed #294479.
+ (Martin Pool, #303856)
+
+* Properly handle when a revision can be inserted as a delta versus
+ when it needs to be expanded to a fulltext for stacked branches.
+ There was a bug involving merge revisions. As a method to help
+ prevent future difficulties, also make stacked fetches sort
+ topologically. (John Arbash Meinel, #304841)
+
+
+bzr 1.10rc1
+###########
+
+:Released: 2008-11-28
+
+This release of Bazaar focuses on performance improvements when pushing
+and pulling revisions, both locally and to remote networks. The popular
+``shelve`` and ``unshelve`` commands, used to interactively revert and
+restore work in progress, have been merged from bzrtools into the bzr
+core. There are also bug fixes for portability, and for stacked branches.
+
+New Features
+************
+
+* New ``commit_message_template`` hook that is called by the commit
+ code to generate a template commit message. (Jelmer Vernooij)
+
+* New `shelve` and `unshelve` commands allow undoing and redoing changes.
+ (Aaron Bentley)
+
+Improvements
+************
+
+* ``(Remote)Branch.copy_content_into`` no longer generates the full revision
+ history just to set the last revision info.
+ (Andrew Bennetts, John Arbash Meinel)
+
+* Fetches between formats with different serializers (such as
+ pack-0.92-subtree and 1.9-rich-root) are faster now. This is due to
+ operating on batches of 100 revisions at time rather than
+ one-by-one. (Andrew Bennetts, John Arbash Meinel)
+
+* Search index files corresponding to pack files we've already used
+ before searching others, because they are more likely to have the
+ keys we're looking for. This reduces the number of iix and tix
+ files accessed when pushing 1 new revision, for instance.
+ (John Arbash Meinel)
+
+* Signatures to transfer are calculated more efficiently in
+ ``item_keys_introduced_by``. (Andrew Bennetts, John Arbash Meinel)
+
+* The generic fetch code can once again copy revisions and signatures
+ without extracting them completely to fulltexts and then serializing
+ them back down into byte strings. This is a significant performance
+ improvement when fetching from a stacked branch.
+ (John Arbash Meinel, #300289)
+
+* When making a large readv() request over ``bzr+ssh``, break up the
+ request into more manageable chunks. Because the RPC is not yet able
+ to stream, this helps keep us from buffering too much information at
+ once. (John Arbash Meinel)
+
+Bug Fixes
+*********
+
+* Better message when the user needs to set their Launchpad ID.
+ (Martin Pool, #289148)
+
+* ``bzr commit --local`` doesn't access the master branch anymore.
+ This fixes a regression introduced in 1.9. (Marius Kruger, #299313)
+
+* Don't call the system ``chdir()`` with an empty path. Sun OS seems
+ to give an error in that case. Also, don't count on ``getcwd()``
+ being able to allocate a new buffer, which is a gnu extension.
+ (John Arbash Meinel, Martin Pool, Harry Hirsch, #297831)
+
+* Don't crash when requesting log --forward <file> for a revision range
+ starting with a dotted revno.
+ (Vincent Ladeuil, #300055)
+
+* Don't create text deltas spanning stacked repositories; this could
+ cause "Revision X not present in Y" when later accessing them.
+ (Martin Pool, #288751)
+
+* Pack repositories are now able to reload the pack listing and retry
+ the current operation if another action causes the data to be
+ repacked. (John Arbash Meinel, #153786)
+
+* PermissionDenied errors from smart servers no longer cause
+ "PermissionDenied: "None"" on the client.
+ (Andrew Bennetts, #299254)
+
+* Pushing to a stacked pack repository now batches writes, the same
+ way writes are batched to ordinary pack repository. This makes
+ pushing to a stacked branch over the network much faster.
+ (Andrew Bennetts, #294479)
+
+* TooManyConcurrentRequests no longer occur when a fetch fails and
+ tries to abort a write group. This allows the root cause (e.g. a
+ network interruption) to be reported. (Andrew Bennetts, #297014)
+
+* RemoteRepository.get_parent_map now uses fallback repositories.
+ (Aaron Bentley, #297991?, #293679?)
+
+API Changes
+***********
+
+* ``CommitBuilder`` now validates the strings it will be committing,
+ to ensure that they do not have characters that will not be properly
+ round-tripped. For now, it just checks for characters that are
+ invalid in the XML form. (John Arbash Meinel, #295161)
+
+* Constructor parameters for NewPack (internal to pack repositories)
+ have changed incompatibly.
+
+* ``Repository.abort_write_group`` now accepts an optional
+ ``suppress_errors`` flag. Repository implementations that override
+ ``abort_write_group`` will need to be updated to accept the new
+ argument. Subclasses that only override ``_abort_write_group``
+ don't need to change.
+
+* Transport implementations must provide copy_tree_to_transport. A default
+ implementation is provided for Transport subclasses.
+
+Testing
+*******
+
+* ``bzr selftest`` now fails if no doctests are found in a module
+ that's expected to have them. (Martin Pool)
+
+* Doctests now only report the first failure. (Martin Pool)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.11.txt b/doc/en/release-notes/bzr-1.11.txt
new file mode 100644
index 0000000..d673b0c
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.11.txt
@@ -0,0 +1,278 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.11
+########
+
+:Codename: "Eyes up!"
+:Released: 2009-01-19
+
+This first monthly release of Bazaar for 2009 improves Bazaar's operation
+in Windows, Mac OS X, and other situations where file names are matched
+without regard to capitalization: Bazaar tries to match the case of an
+existing file. This release of Bazaar also improves the efficiency of
+Tortoise Windows Shell integration and lets it work on 64-bit platforms.
+
+The UI through which Bazaar supports historic formats has been improved,
+so 'bzr help formats' now gives a simpler and shorter list, with clear
+advice.
+
+This release also fixes a number of bugs, particularly a glitch that can
+occur when there are concurrent writes to a pack repository.
+
+Bug Fixes
+*********
+
+* Fix failing test when CompiledChunksToLines is not available.
+ (Vincent Ladeuil)
+
+* Stacked branches don't repeatedly open their transport connection.
+ (John Arbash Meinel)
+
+
+
+bzr 1.11rc1
+###########
+
+:Codename: "Eyes up!"
+:Released: 2009-01-09
+
+Changes
+*******
+
+* Formats using Knit-based repository formats are now explicitly
+ marked as deprecated. (Ian Clatworthy)
+
+New Features
+************
+
+* Add support for `bzr tags -r 1..2`, that is we now support showing
+ tags applicable for a specified revision range. (Marius Kruger)
+
+* ``authentication.conf`` now accepts pluggable read-only credential
+ stores. Such a plugin (``netrc_credential_store``) is now included,
+ handles the ``$HOME/.netrc`` file and can server as an example to
+ implement other plugins.
+ (Vincent Ladeuil)
+
+* ``shelve --list`` can now be used to list shelved changes.
+ (Aaron Bentley)
+
+Improvements
+************
+
+* Add trailing slash to directories in all output of ``bzr ls``, except
+ ``bzr ls --null``. (Gordon P. Hemsley, #306424)
+
+* ``bzr revision-info`` now supports a -d option to specify an
+ alternative branch. (Michael Hudson)
+
+* Add connection to a C++ implementation of the Windows Shell Extension
+ which is able to fully replace the current Python implemented one.
+ Advantages include 64bit support and reduction in overhead for
+ processes which drag in shell extensions.
+ (Mark Hammond)
+
+* Support the Claws mail client directly, rather than via
+ xdg-email. This prevents the display of an unnecessary modal
+ dialog in Claws, informing the user that a file has been
+ attached to the message, and works around bug #291847 in
+ xdg-utils which corrupts the destination address.
+
+* When working on a case-insensitive case-preserving file-system, as
+ commonly found with Windows, bzr will often ignore the case of the
+ arguments specified by the user in preference to the case of an existing
+ item on the file-system or in the inventory to help prevent
+ counter-intuitive behaviour on Windows. (Mark Hammond)
+
+Bug Fixes
+*********
+
+* Allow BzrDir implementation to implement backing up of
+ control directory. (#139691)
+
+* ``bzr push`` creating a new stacked branch will now only open a
+ single connection to the target machine. (John Arbash Meinel)
+
+* Don't call iteritems on transport_list_registry, because it may
+ change during iteration. (Martin Pool, #277048)
+
+* Don't make a broken branch when pushing an unstackable-format branch
+ that's in a stackable shared repository to a location with default
+ stack-on location. (Andrew Bennetts, #291046)
+
+* Don't require embedding user in HTTP(S) URLs do use authentication.conf.
+ (Ben Jansen, Vincent Ladeuil, #300347)
+
+* Fix a problem with CIFS client/server lag on windows colliding with
+ an invariant-per-process algorithm for generating AtomicFile names
+ (Adrian Wilkins, #304023)
+
+* Fix bogus setUp signature in UnavailableFTPServer.
+ (Gary van der Merwe, #313498)
+
+* Fix compilation error in ``_dirstate_helpers_c`` on SunOS/Solaris.
+ (Jari Aalto)
+
+* Fix SystemError in ``_patiencediff_c`` module by calling
+ PyErr_NoMemory() before returning NULL in PatienceSequenceMatcher_new.
+ (Andrew Bennetts, #303206)
+
+* Give proper error message for diff with non-existent dotted revno.
+ (Marius Kruger, #301969)
+
+* Handle EACCES (permission denied) errors when launching a message
+ editor, and emit warnings when a configured editor cannot be
+ started. (Andrew Bennetts)
+
+* ``$HOME/.netrc`` file is now recognized as a read-only credential store
+ if configured in ``authentication.conf`` with 'password_encoding=netrc'
+ in the appropriate sections.
+ (Vincent Ladeuil, #103029)
+
+* Opening a stacked branch now properly shares the connection, rather
+ than opening a new connection for the stacked-on branch.
+ (John Arbash meinel)
+
+* Preserve transport decorators while following redirections.
+ (Vincent Ladeuil, #245964, #270863)
+
+* Provides a finer and more robust filter for accepted redirections.
+ (Vincent Ladeuil, #303959, #265070)
+
+* ``shelve`` paths are now interpreted relative to the current working
+ tree. (Aaron Bentley)
+
+* ``Transport.readv()`` defaults to not reading more than 100MB in a
+ single array. Further ``RemoteTransport.readv`` sets this to 5MB to
+ work better with how it splits its requests.
+ (John Arbash Meinel, #303538)
+
+* Pack repositories are now able to reload the pack listing and retry
+ the current operation if another action causes the data to be
+ repacked. (John Arbash Meinel, #153786)
+
+* ``pull -v`` now respects the log_format configuration variable.
+ (Aaron Bentley)
+
+* ``push -v`` now works on non-initial pushes. (Aaron Bentley)
+
+* Use the short status format when the short format is used for log.
+ (Vincent Ladeuil, #87179)
+
+* Allow files to be renamed or moved via remove + add-by-id. (Charles
+ Duffy, #314251)
+
+Documentation
+*************
+
+* Improved the formats help topic to explain why multiple formats
+ exist and to provide guidelines in selecting one. Introduced
+ two new supporting help topics: current-formats and other-formats.
+ (Ian Clatworthy)
+
+API Changes
+***********
+
+* ``LRUCache(after_cleanup_size)`` was renamed to
+ ``after_cleanup_count`` and the old name deprecated. The new name is
+ used for clarity, and to avoid confusion with
+ ``LRUSizeCache(after_cleanup_size)``. (John Arbash Meinel)
+
+* New ``ForeignRepository`` base class, to help with foreign branch
+ support (e.g. svn). (Jelmer Vernooij)
+
+* ``node_distances`` and ``select_farthest`` can no longer be imported
+ from ``bzrlib.graph``. They can still be imported from
+ ``bzrlib.deprecated_graph``, which has been the preferred way to
+ import them since before 1.0. (Andrew Bennetts)
+
+* The logic in commit now delegates inventory basis calculations to
+ the ``CommitBuilder`` object; this requires that the commit builder
+ in use has been updated to support the new ``recording_deletes`` and
+ ``record_delete`` methods. (Robert Collins)
+
+Testing
+*******
+
+* An HTTPS server is now available (it requires python-2.6). Future bzr
+ versions will allow the use of the python-2.6 ssl module that can be
+ installed for 2.5 and 2.4.
+
+* ``bzr selftest`` now fails if new trailing white space is added to
+ the bazaar sources. It only checks changes not committed yet. This
+ means that PQM will now reject changes that introduce new trailing
+ whitespace. (Marius Kruger)
+
+* Introduced new experimental formats called ``1.12-preview`` and
+ ``1.12-preview-rich-root`` to enable testing of related pending
+ features, namely content filtering and filtered views.
+ (Ian Clatworthy)
+
+Internals
+*********
+
+* Added an ``InventoryEntry`` cache when deserializing inventories.
+ Can cut the time to iterate over multiple RevisionsTrees in half.
+ (John Arbash Meinel)
+
+* Added ``bzrlib.fifo_cache.FIFOCache`` which is designed to have
+ minimal overhead versus using a plain dict for cache hits, at the
+ cost of not preserving the 'active' set as well as an ``LRUCache``.
+ (John Arbash Meinel)
+
+* ``bzrlib.patience_diff.unified_diff`` now properly uses a tab
+ character to separate the filename from the date stamp, and doesn't
+ add trailing whitespace when a date stamp is not supplied.
+ (Adeodato Simó, John Arbash Meinel)
+
+* ``DirStateWorkingTree`` and ``DirStateWorkingTreeFormat`` added
+ as base classes of ``WorkingTree4`` and ``WorkingTreeFormat4``
+ respectively. (Ian Clatworthy)
+
+* ``KnitVersionedFiles._check_should_delta()`` now uses the
+ ``get_build_details`` api to avoid multiple hits to the index, and
+ to properly follow the ``compression_parent`` rather than assuming
+ it is the left-hand parent. (John Arbash Meinel)
+
+* ``KnitVersionedFiles.get_record_stream()`` will now chose a
+ more optimal ordering when the keys are requested 'unordered'.
+ Previously the order was fully random, now the records should be
+ returned from each pack in turn, in forward I/O order.
+ (John Arbash Meinel)
+
+* ``mutter()`` will now flush the ``~/.bzr.log`` if it has been more
+ than 2s since the last time it flushed. (John Arbash Meinel)
+
+* New method ``bzrlib.repository.Repository.add_inventory_by_delta``
+ allows adding an inventory via an inventory delta, which can be
+ more efficient for some repository types. (Robert Collins)
+
+* Repository ``CommitBuilder`` objects can now accumulate an inventory
+ delta. To enable this functionality call ``builder.recording_deletes``
+ and additionally call ``builder.record_delete`` when a delete
+ against the basis occurs. (Robert Collins)
+
+* The default HTTP handler has been changed from pycurl to urllib.
+ The default is still pycurl for https connections. (The only
+ advantage of pycurl is that it checks ssl certificates.)
+ (John Arbash Meinel)
+
+* ``VersionedFiles.get_record_stream()`` can now return objects with a
+ storage_kind of ``chunked``. This is a collection (list/tuple) of
+ strings. You can use ``osutils.chunks_to_lines()`` to turn them into
+ guaranteed 'lines' or you can use ``''.join(chunks)`` to turn it
+ into a fulltext. This allows for some very good memory savings when
+ asking for many texts that share ancestry, as the individual chunks
+ can be shared between versions of the file. (John Arbash Meinel)
+
+* ``pull -v`` and ``push -v`` use new function
+ ``bzrlib.log.show_branch_change`` (Aaron Bentley)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.12.txt b/doc/en/release-notes/bzr-1.12.txt
new file mode 100644
index 0000000..1d4afab
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.12.txt
@@ -0,0 +1,227 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.12
+########
+
+:Codename: 1234567890
+:1.12: 2009-02-13
+:1.12rc1: 2009-02-10
+
+This release of Bazaar contains many improvements to the speed,
+documentation and functionality of ``bzr log`` and the display of logged
+revisions by ``bzr status``. bzr now also gives a better indication of
+progress, both in the way operations are drawn onto a text terminal, and
+by showing the rate of network IO.
+
+Changes from RC1 to Final
+*************************
+
+* ``bzr init --development-wt5[-rich-root]`` would fail because of
+ circular import errors. (John Arbash Meinel, #328135)
+
+* Expanded the help for log and added a new help topic called
+ ``log-formats``. (Ian Clatworthy)
+
+Compatibility Breaks
+********************
+
+* By default, ``bzr status`` after a merge now shows just the pending
+ merge tip revisions. This improves the signal-to-noise ratio after
+ merging from trunk and completes much faster. To see all merged
+ revisions, use the new ``-v`` flag. (Ian Clatworthy)
+
+* ``bzr log --line`` now shows any tags after the date and before
+ the commit message. If you have scripts which parse the output
+ from this command, you may need to adjust them accordingly.
+ (Ian Clatworthy)
+
+* ``bzr log --short`` now shows any additional revision properties
+ after the date and before the commit message. Scripts that parse
+ output of the log command in this situation may need to adjust.
+ (Neil Martinsen-Burrell)
+
+* The experimental formats ``1.12-preview`` and ``1.12-preview-rich-root``
+ have been renamed ``development-wt5`` and ``development-wt5-rich-root``
+ respectively, given they are not ready for release in 1.12.
+ (Ian Clatworthy)
+
+* ``read_bundle_from_url`` has been deprecated. (Vincent Ladeuil)
+
+New Features
+************
+
+* Add support for filtering ``bzr missing`` on revisions. Remote revisions
+ can be filtered using ``bzr missing -r -20..-10`` and local revisions can
+ be filtered using ``bzr missing --my-revision -20..-10``.
+ (Marius Kruger)
+
+* ``bzr log -p`` displays the patch diff for each revision.
+ When logging a file, the diff only includes changes to that file.
+ (Ian Clatworthy, #202331, #227335)
+
+* ``bzr log`` supports a new option called ``-n N`` or ``--level N``.
+ A value of 0 (zero) means "show all nested merge revisions" while
+ a value of 1 (one) means "show just the top level". Values above
+ 1 can be used to see a limited amount of nesting. That can be
+ useful for seeing the level or two below PQM submits for example.
+ To force the ``--short`` and ``--line`` formats to display all nested
+ merge revisions just like ``--long`` does by default, use a command
+ like ``bzr log --short -n0``. To display just the mainline using
+ ``--long`` format, ``bzr log --long -n1``.
+ (Ian Clatworthy)
+
+Improvements
+************
+
+* ``bzr add`` more clearly communicates success vs failure.
+ (Daniel Watkins)
+
+* ``bzr init`` will now print a little less verbose output.
+ (Marius Kruger)
+
+* ``bzr log`` is now much faster in many use cases, particularly
+ at incrementally displaying results and filtering by a
+ revision range. (Ian Clatworthy)
+
+* ``bzr log --short`` and ``bzr log --line`` now show tags, if any,
+ for each revision. The tags are shown comma-separated inside
+ ``{}``. For short format, the tags appear at the end of line
+ before the optional ``[merge]`` indicator. For line format,
+ the tags appear after the date. (Ian Clatworthy)
+
+* Progress bars now show the rate of activity for some SFTP
+ operations, and they are drawn different. (Martin Pool, #172741)
+
+* Progress bars now show the rate of activity for urllib and pycurl based
+ HTTP client implementations. The operations are tracked at the socket
+ level for better precision.
+ (Vincent Ladeuil)
+
+* Rule-based preferences can now accept multiple patterns for a set of
+ rules. (Marius Kruger)
+
+* The ``ancestor:`` revision spec will now default to referring to the
+ parent of the branch if no other location is given.
+ (Daniel Watkins, #198417)
+
+* The debugger started as a result of setting ``$BZR_PDB`` works
+ around a bug in ``pdb``, http://bugs.python.org/issue4150. The bug
+ can cause truncated tracebacks in Python versions before 2.6.
+ (Andrew Bennetts)
+
+* VirtualVersionedFiles now implements
+ ``iter_lines_added_or_present_in_keys``. This allows the creation of
+ new branches based on stacked bzr-svn branches. (#311997)
+
+Bug Fixes
+*********
+
+* ``bzr annotate --show-ids`` doesn't give a backtrace on empty files
+ anymore.
+ (Anne Mohsen, Vincent Ladeuil, #314525)
+
+* ``bzr log FILE`` now correctly shows mainline revisions merging
+ a change to FILE when the ``--short`` and ``--line`` log formats
+ are used. (Ian Clatworthy, #317417)
+
+* ``bzr log -rX..Y FILE`` now shows the history of FILE provided
+ it existed in Y or X, even if the file has since been deleted or
+ renamed. If no range is given, the current/basis tree and
+ initial tree are searched in that order. More generally, log
+ now interprets filenames in their historical context.
+ (Ian Clatworthy, #175520)
+
+* ``bzr status`` now reports nonexistent files and continues, then
+ errors (with code 3) at the end. (Karl Fogel, #306394)
+
+* Don't require the present compression base in knits to be the same
+ when adding records in knits. (Jelmer Vernooij, #307394)
+
+* Fix a problem with CIFS client/server lag on Windows colliding with
+ an invariant-per-process algorithm for generating AtomicFile names
+ (Adrian Wilkins, #304023)
+
+* Many socket operations now handle EINTR by retrying the operation.
+ Previously EINTR was treated as an unrecoverable failure. There is
+ a new ``until_no_eintr`` helper function in ``bzrlib.osutils``.
+ (Andrew Bennetts)
+
+* Support symlinks with non-ascii characters in the symlink filename.
+ (Jelmer Vernooij, #319323)
+
+* There was a bug in how we handled resolving when a file is deleted
+ in one branch, and modified in the other. If there was a criss-cross
+ merge, we would cause the deletion to conflict a second time.
+ (Vincent Ladeuil, John Arbash Meinel)
+
+* There was another bug in how we chose the correct intermediate LCA in
+ criss-cross merges leading to several kind of changes be incorrectly
+ handled.
+ (John Arbash Meinel, Vincent Ladeuil)
+
+* Unshelve now handles deleted paths without crashing. (Robert Collins)
+
+Documentation
+*************
+
+* Improved plugin developer documentation. (Martin Pool)
+
+API Changes
+***********
+
+* ``ProgressBarStack`` is deprecated; instead use
+ ``ui_factory.nested_progress_bar`` to create new progress bars.
+ (Martin Pool)
+
+* ForeignVcsMapping() now requires a ForeignVcs object as first
+ argument. (Jelmer Vernooij)
+
+* ForeignVcsMapping.show_foreign_revid() has been moved to
+ ForeignVcs. (Jelmer Vernooij)
+
+* ``read_bundle_from_url`` is deprecated in favor of
+ ``read_mergeable_from_url``. (Vincent Ladeuil)
+
+* Revision specifiers are now registered in
+ ``bzrlib.revisionspec.revspec_registry``, and the old list of
+ revisionspec classes (``bzrlib.revisionspec.SPEC_TYPES``) has been
+ deprecated. (Jelmer Vernooij, #321183)
+
+* The progress and UI classes have changed; the main APIs remain the
+ same but code that provides a new UI or progress bar class may
+ need to be updated. (Martin Pool)
+
+Internals
+*********
+
+* Default User Interface (UI) is CLIUIFactory when bzr runs in a dumb
+ terminal. It is sometimes desirable do override this default by forcing
+ bzr to use TextUIFactory. This can be achieved by setting the
+ BZR_USE_TEXT_UI environment variable (emacs shells, as opposed to
+ compile buffers, are such an example).
+ (Vincent Ladeuil)
+
+* New API ``Branch.iter_merge_sorted_revisions()`` that iterates over
+ ``(revision_id, depth, revno, end_of_merge)`` tuples.
+ (Ian Clatworthy)
+
+* New ``Branch.dotted_revno_to_revision_id()`` and
+ ``Branch.revision_id_to_dotted_revno()`` APIs that pick the most
+ efficient way of doing the mapping.
+ (Ian Clatworthy)
+
+* Refactor cmd_serve so that it's a little easier to build commands that
+ extend it, and perhaps even a bit easier to read. (Jonathan Lange)
+
+* ``TreeDelta.show()`` now accepts a ``filter`` parameter allowing log
+ formatters to retrict the output.
+ (Vincent Ladeuil)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.13.txt b/doc/en/release-notes/bzr-1.13.txt
new file mode 100644
index 0000000..c867075
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.13.txt
@@ -0,0 +1,400 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+
+bzr 1.13
+########
+
+:Codename: paraskavedekatriaphobia
+:1.13: 2009-03-14
+:1.13rc1: 2009-03-10
+:1.13.1: 2009-03-23
+:1.13.2: 2009-04-27
+
+GNU Changelog output can now be produced by ``bzr log --gnu-changelog``. Debug
+flags can now be set in ``~/.bazaar/bazaar.conf``. Lightweight checkouts and
+stacked branches should both be much faster over remote connections.
+
+Changes From 1.13.1 to 1.13.2
+*****************************
+
+A regression was found in the 1.13.1 release. When bzr 1.13.1 and earlier push
+a stacked branch they do not take care to push all the parent inventories for
+the transferred revisions. This means that a smart server serving that branch
+often cannot calculate inventory deltas for the branch (because smart server
+does not/cannot open fallback repositories). Prior to 1.13 the server did not
+have a verb to stream revisions out of a repository, so that's why this bug has
+appeared now.
+
+Bug Fixes
+*********
+
+* Fix for bug 354036 ErrorFromSmartServer - AbsentContentFactory object has no
+ attribute 'get_bytes_as' exception while pulling from Launchpad
+ (Jean-Francois Roy, Andrew Bennetts, Robert Collins)
+
+Changes From 1.13final to 1.13.1
+********************************
+
+A couple regessions where found in the 1.13 release. The pyrex-generated C
+extensions are missing from the .tar.gz and .zip files. Documentation on how
+to generate GNU ChangeLogs is wrong.
+
+Bug Fixes
+*********
+
+* Change ``./bzr``'s ``_script_version`` to match ./bzrlib/__init__.py
+ version_info. (Bob Tanner, Martin Pool, #345232)
+
+* Distribution archives for 1.13 do not contain generated C extension modules
+ (Jean-Francois Roy, Bob Tanner, #344465)
+
+* GNU ChangeLog output can now be produced by bzr log --format gnu-changelog is
+ incorrect (Deejay, Bob Tanner, Martin Pool, Robert Collins, #343928)
+
+* ``merge --force`` works again. (Robert Collins, #342105)
+
+Changes From 1.13rc1 to 1.13final
+*********************************
+
+* Fix "is not a stackable format" error when pushing a
+ stackable-format branch with an unstackable-format repository to a
+ destination with a default stacking policy. (Andrew Bennetts)
+
+* Progress bars now show the rate of network activity for
+ ``bzr+ssh://`` and ``bzr://`` connections. (Andrew Bennetts)
+
+Compatibility Breaks
+********************
+
+* ``bzr log --line`` now indicates which revisions are merges with
+ `[merge]` after the date. Scripts which parse the output of this
+ command may need to be adjusted.
+ (Neil Martinsen-Burrell)
+
+New Features
+************
+
+* ``bzr reconfigure`` now supports --with-trees and --with-no-trees
+ options to change the default tree-creation policy of shared
+ repositories. (Matthew Fuller, Marius Kruger, #145033)
+
+* Debug flags can now be set in ``~/.bazaar/bazaar.conf``.
+ (Martin Pool)
+
+* Filtered views provide a mask over the tree so that users can focus
+ on a subset of a tree when doing their work. See ``Filtered views``
+ in chapter 7 of the User Guide and ``bzr help view`` for details.
+ (Ian Clatworthy)
+
+* GNU Changelog output can now be produced by ``bzr log --gnu-changelog``.
+ (Andrea Bolognani, Martin Pool)
+
+* The ``-Dmemory`` flag now gives memory information on Windows.
+ (John Arbash Meinel)
+
+* Multiple authors for a commit can now be recorded by using the "--author"
+ option multiple times. (James Westby, #185772)
+
+* New clean-tree command, from bzrtools. (Aaron Bentley, Jelmer Vernooij)
+
+* New command ``bzr launchpad-open`` opens a Launchpad web page for that
+ branch in your web browser, as long as the branch is on Launchpad at all.
+ (Jonathan Lange)
+
+* New API for getting bugs fixed by a revision: Revision.iter_bugs().
+ (Jonathan Lange)
+
+Improvements
+************
+
+* All bzr ``Hooks`` classes are now registered in
+ ``bzrlib.hooks.known_hooks``. This removes the separate list from
+ ``bzrlib.tests`` and ensures that all hooks registered there are
+ correctly isolated by the test suite (previously
+ ``MutableTreeHooks`` were not being isolated correctly). Further,
+ documentation for hooks is now dynamically generated from the
+ present HookPoints. ``bzr hooks`` will now also report on all the
+ hooks present in the ``bzrlib.hooks.known_hooks`` registry.
+ (Robert Collins)
+
+* ``bzr add`` no longer prints ``add completed`` on success. Failure
+ still prints an error message. (Robert Collins)
+
+* ``bzr branch`` now has a ``--no-tree`` option which turns off the
+ generation of a working tree in the new branch.
+ (Daniel Watkins, John Klinger, #273993)
+
+* Bazaar will now point out ``bzr+ssh://`` to the user when they
+ use ssh://. (Jelmer Vernooij, #330535)
+
+* ``bzr -v info`` now omits the number of committers branch statistic,
+ making it many times faster for large projects. To include that
+ statistic in the output, use ``bzr -vv info``.
+ (Ian Clatworthy)
+
+* ``bzr push`` to a ``bzr`` url (``bzr://``, ``bzr+ssh://`` etc) will
+ stream if the server is version 1.13 or greater, reducing roundtrips
+ significantly. (Andrew Bennetts, Robert Collins)
+
+* Lightweight Checkouts and Stacked Branches should both be much
+ faster over remote connections. Building the working tree now
+ batches up requests into approx 5MB requests, rather than a separate
+ request for each file. (John Arbash Meinel)
+
+* Support for GSSAPI authentication when using HTTP or HTTPS.
+ (Jelmer Vernooij)
+
+* The ``bzr shelve`` prompt now includes a '?' help option to explain the
+ short options better. (Daniel Watkins, #327429)
+
+* ``bzr lp-open`` now falls back to the push location if it cannot find a
+ public location. (Jonathan Lange, #332372)
+
+* ``bzr lp-open`` will try to find the Launchpad URL for the location
+ passed on the command line. This makes ``bzr lp-open lp:foo`` work as
+ expected. (Jonathan Lange, #332705)
+
+* ``bzr send`` now supports MH-E via ``emacsclient``. (Eric Gillespie)
+
+Bug Fixes
+*********
+
+* Allows ``bzr log <FILE>`` to be called in an empty branch without
+ backtracing. (Vincent Ladeuil, #346431)
+
+* Bazaar now gives a better message including the filename if it's
+ unable to read a file in the working directory, for example because
+ of a permission error. (Martin Pool, #338653)
+
+* ``bzr cat -r<old> <path>`` doesn't traceback anymore when <path> has a
+ file id in the working tree different from the one in revision <old>.
+ (Vincent Ladeuil, #341517, #253806)
+
+* ``bzr send`` help is more specific about how to apply merge
+ directives. (Neil Martinsen-Burrell, #253470)
+
+* ``bzr missing`` now uses ``Repository.get_revision_delta()`` rather
+ than fetching trees and determining a delta itself. (Jelmer
+ Vernooij, #315048)
+
+* ``bzr push`` to a smart server no longer causes "Revision
+ {set([('null:',)])} not present ..." errors when the branch has
+ multiple root revisions. (Andrew Bennetts, #317654)
+
+* ``bzr shelve`` now properly handle patches with no terminating newline.
+ (Benoît PIERRE, #303569)
+
+* ``bzr unshelve`` gives a more palatable error if passed a non-integer
+ shelf id. (Daniel Watkins)
+
+* Export now handles files that are not present in the tree.
+ (James Westby, #174539)
+
+* Fixed incorrect "Source format does not support stacking" warning
+ when pushing to a smart server. (Andrew Bennetts, #334114)
+
+* Fixed "sprout() got an unexpected keyword argument 'source_branch'"
+ error branching from old repositories.
+ (Martin Pool, #321695)
+
+* Make ``bzr push --quiet <non-local location>`` less chatty.
+ (Kent Gibson, #221461)
+
+* Many Branch hooks would not fire with ``bzr://`` and ``bzr+ssh://``
+ branches, and this was not noticed due to a bug in the test logic
+ for branches. This is now fixed and a test added to prevent it
+ reoccuring. (Robert Collins, Andrew Bennetts)
+
+* Restore the progress bar on Windows. We were disabling it when TERM
+ wasn't set, but Windows doesn't set TERM. (Alexander Belchenko,
+ #334808)
+
+* ``setup.py build_ext`` now gives a proper error when an extension
+ fails to build. (John Arbash Meinel)
+
+* Symlinks to non ascii file names are now supported.
+ (Robert Collins, Vincent Ladeuil, #339055, #272444)
+
+* Under rare circumstances (aka nobody reported a bug about it), the FTP
+ transport could revert to ascii mode. It now stays in binary mode except
+ when needed. (Vincent Ladeuil)
+
+* Unshelve does not generate warnings about progress bars.
+ (Aaron Bentley, #328148)
+
+* shelve cleans up properly when unversioned files are specified.
+ (Benoît Pierre, Aaron Bentley)
+
+Documentation
+*************
+
+* Added ``Organizing your workspace`` to the User Guide appendices,
+ summarizing some common ways of organizing trees, branches and
+ repositories and the processes/workflows implied/enabled by each.
+ (Ian Clatworthy)
+
+* Hooks can now be self documenting. ``bzrlib.hooks.Hooks.create_hook``
+ is the entry point for this feature. (Robert Collins)
+
+* The documentation for ``shelve`` and ``unshelve`` has been clarified.
+ (Daniel Watkins, #327421, #327425)
+
+API Changes
+***********
+
+* ``bzr selftest`` now fails if the bazaar sources contain trailing
+ whitespace, non-unix style line endings and files not ending in a
+ newline. About 372 files and 3243 lines with trailing whitespace was
+ updated to comply with this. The code already complied with the other
+ criteria, but now it is enforced. (Marius Kruger)
+
+* ``bzrlib.branch.PushResult`` was renamed to
+ ``bzrlib.branch.BranchPushResult``. (Jelmer Vernooij)
+
+* ``Branch.fetch`` and ``Repository.fetch`` now return None rather
+ than a count of copied revisions and failed revisions. A while back
+ we stopped ever reporting failed revisions because we started
+ erroring instead, and the copied revisions count is not used in the
+ UI at all - indeed it only reflects the repository status not
+ changes to the branch itself. (Robert Collins)
+
+* ``Inventory.apply_delta`` now raises an AssertionError if a file-id
+ appears multiple times within the delta. (Ian Clatworthy)
+
+* MutableTree.commit now favours the "authors" argument, with the old
+ "author" argument being deprecated.
+
+* Remove deprecated EmptyTree. (Martin Pool)
+
+* ``Repository.fetch`` now accepts an optional ``fetch_spec``
+ parameter. A ``SearchResult`` or ``MiniSearchResult`` may be passed
+ to ``fetch_spec`` instead of a ``last_revision`` to specify exactly
+ which revisions to fetch. (Andrew Bennetts)
+
+* ``RepositoryAcquisitionPolicy.acquire_repository`` now returns a
+ tuple of ``(repository, is_new_flag)``, rather than just the
+ repository. (Andrew Bennetts)
+
+* Revision.get_apparent_author() is now deprecated, replaced by
+ Revision.get_apparent_authors(), which returns a list. The former
+ now returns the first item that would be returned from the second.
+
+* The ``BranchBuilder`` test helper now accepts a ``timestamp``
+ parameter to ``build_commit`` and ``build_snapshot``. (Martin Pool)
+
+* The ``_fetch_*`` attributes on ``Repository`` are now on
+ ``RepositoryFormat``, more accurately reflecting their intent (they
+ describe a disk format capability, not state of a particular
+ repository of that format). (Robert Collins)
+
+Internals
+*********
+
+* Branching from a non-stacked branch on a smart protocol is now
+ free of virtual file system methods.
+ (Robert Collins, Andrew Bennetts)
+
+* Branch and Repository creation on a bzr+ssh://server are now done
+ via RPC calls rather than VFS calls, reducing round trips for
+ pushing new branches substantially. (Robert Collins)
+
+* ``Branch.clone`` now takes the ``repository_policy`` formerly used
+ inside ``BzrDir.clone_on_transport``, allowing stacking to be
+ configured before the branch tags and revision tip are set. This
+ fixes a race condition cloning stacked branches that would cause
+ plugins to have hooks called on non-stacked instances.
+ (Robert Collins, #334187)
+
+* ``BzrDir.cloning_metadir`` now has a RPC call. (Robert Collins)
+
+* ``BzrDirFormat.__str__`` now uses the human readable description
+ rather than the sometimes-absent disk label. (Robert Collins)
+
+* ``bzrlib.fetch`` is now composed of a sender and a sink component
+ allowing for decoupling over a network connection. Fetching from
+ or into a RemoteRepository with a 1.13 server will use this to
+ stream the operation.
+ (Andrew Bennetts, Robert Collins)
+
+* ``bzrlib.tests.run_suite`` accepts a runner_class parameter
+ supporting the use of different runners. (Robert Collins)
+
+* Change how file_ids and revision_ids are interned as part of
+ inventory deserialization. Now we use the real ``intern()``, rather
+ than our own workaround that would also cache a Unicode copy of the
+ string, and never emptied the cache. This should slightly reduce
+ memory consumption. (John Arbash Meinel)
+
+* New branch method ``create_clone_on_transport`` that returns a
+ branch object. (Robert Collins)
+
+* New hook Commands['extend_command'] to allow plugins to access a
+ command object before the command is run (or help generated from
+ it), without overriding the command. (Robert Collins)
+
+* New version of the ``BzrDir.find_repository`` verb supporting
+ ``_network_name`` to support removing more _ensure_real calls.
+ (Robert Collins)
+
+* ``RemoteBranchFormat`` no longer claims to have a disk format string.
+ (Robert Collins)
+
+* ``Repository`` objects now have ``suspend_write_group`` and
+ ``resume_write_group`` methods. These are currently only useful
+ with pack repositories. (Andrew Bennetts, Robert Collins)
+
+* ``BzrDirFormat``, ``BranchFormat`` and ``RepositoryFormat`` objects
+ now have a ``network_name`` for passing the format across RPC calls.
+ (Robert Collins, Andrew Bennetts)
+
+* ``RepositoryFormat`` objects now all have a new attribute
+ ``_serializer`` used by fetch when reserialising is required.
+ (Robert Collins, Andrew Bennetts)
+
+* Some methods have been pulled up from ``BzrBranch`` to ``Branch``
+ to aid branch types that are not bzr branch objects (like
+ RemoteBranch). (Robert Collins, Andrew Bennetts)
+
+* Test adaptation has been made consistent throughout the built in
+ tests. ``TestScenarioApplier``, ``multiply_tests_from_modules``,
+ ``adapt_tests``, ``adapt_modules`` have all been deleted. Please
+ use ``multiply_tests``, or for lower level needs ``apply_scenarios``
+ and ``apply_scenario``. (Robert Collins)
+
+* ``TestSkipped`` is now detected by TestCase and passed to the
+ ``TestResult`` by calling ``addSkip``. For older TestResult objects,
+ where ``addSkip`` is not available, ``addError`` is still called.
+ This permits test filtering in subunit to strip out skipped tests
+ resulting in a faster fix-shrink-list-run cycle. This is compatible
+ with the testtools protocol for skips. (Robert Collins)
+
+* The ``_index`` of ``KnitVersionedFiles`` now supports the ability
+ to scan an underlying index that is going to be incorporated into
+ the ``KnitVersionedFiles`` object, to determine if it has missing
+ delta references. The method is ``scan_unvalidated_index``.
+ (Andrew Bennetts, Robert Collins)
+
+* There is a RemoteSink object which handles pushing to smart servers.
+ (Andrew Bennetts, Robert Collins)
+
+* ``TransportTraceDecorator`` now logs ``put_bytes_non_atomic`` and
+ ``rmdir`` calls. (Robert Collins)
+
+* ``VersionedFiles`` record adapters have had their signature change
+ from ``(record, record.get_bytes_as(record.storage_kind))`` to
+ ``(record)`` reducing excess duplication and allowing adapters
+ to access private data in record to obtain content more
+ efficiently. (Robert Collins)
+
+* We no longer probe to see if we should create a working tree during
+ clone if we cannot get a local_abspath for the new bzrdir.
+ (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.14.txt b/doc/en/release-notes/bzr-1.14.txt
new file mode 100644
index 0000000..b367414
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.14.txt
@@ -0,0 +1,459 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.14
+########
+:Codename: brisbane-core
+:1.14rc1: 2009-04-06
+:1.14rc2: 2009-04-19
+:1.14: 2009-04-28
+:1.14.1: 2009-05-01
+
+New formats 1.14 and 1.14-rich-root supporting End-Of-Line (EOL) conversions,
+keyword templating (via the bzr-keywords plugin) and generic content filtering.
+End-of-line conversion is now supported for formats supporting content
+filtering.
+
+Changes from 1.14final to 1.14.1
+********************************
+
+* Change api_minimum_version back to api_minimum_version = (1, 13, 0)
+
+Changes from 1.14rc2 to 1.14final
+*********************************
+
+* Fix a bug in the pure-python ``GroupCompress`` code when handling copies
+ longer than 64KiB. (John Arbash Meinel, #364900)
+
+Changes from 1.14rc1 to 1.14rc2
+*******************************
+
+* Fix for bug 358037 Revision not in
+ bzrlib.groupcompress.GroupCompressVersionedFiles (Brian de Alwis,
+ John A Meinel)
+
+* Fix for bug 354036 ErrorFromSmartServer - AbsentContentFactory object has no
+ attribute 'get_bytes_as' exception while pulling from Launchpad
+ (Jean-Francois Roy, Andrew Bennetts, Robert Collins)
+
+* Fix for bug 355280 eol content filters are never loaded and thus never
+ applied (Brian de Alwis, Ian Clatworthy)
+
+* bzr.dev -r4280 Change _fetch_uses_deltas = False for CHK repos until we can
+ write a better fix. (John Arbash Meinel, Robert Collins)
+
+* Fix for bug 361574 uncommit recommends undefined --levels and -n options
+ (Marius Kruger, Ian Clatworthy)
+
+* bzr.dev r4289 as cherrypicked at lp:~spiv/bzr/stacking-cherrypick-1.14
+ (Andrew Bennetts, Robert Collins)
+
+Compatibility Breaks
+********************
+
+* A previously disabled code path to accelerate getting configuration
+ settings from a smart server has been reinstated. We think this *may*
+ cause a incompatibility with servers older than bzr 0.15. We intend
+ to issue a point release to address this if it turns out to be a
+ problem. (Robert Collins, Andrew Bennetts)
+
+* bzr no longer autodetects nested trees as 'tree-references'. They
+ must now be explicitly added tree references. At the commandline, use
+ join --reference instead of add. (Aaron Bentley)
+
+* The ``--long`` log format (the default) no longer shows merged
+ revisions implicitly, making it consistent with the ``short`` and
+ ``line`` log formats. To see merged revisions for just a given
+ revision, use ``bzr log -n0 -rX``. To see every merged revision,
+ use ``bzr log -n0``. (Ian Clatworthy)
+
+New Features
+************
+
+* New formats ``1.14`` and ``1.14-rich-root`` supporting End-Of-Line
+ (EOL) conversions, keyword templating (via the bzr-keywords plugin)
+ and generic content filtering. These formats replace the experimental
+ ``development-wt5`` and ``development-wt5-rich-root`` formats
+ respectively, but have support for filtered views disabled.
+ (Ian Clatworthy)
+
+* New ``mv --auto`` option recognizes renames after they occur.
+ (Aaron Bentley)
+
+* ``bzr`` can now get passwords from stdin without requiring a controlling
+ terminal (i.e. by redirecting stdin). (Vincent Ladeuil)
+
+* ``bzr log`` now supports filtering of multiple files and directories
+ and will show changes that touch any of them. Furthermore,
+ directory filtering now shows the changes to any children of that
+ directory, not just the directory object itself.
+ (Ian Clatworthy, #97715)
+
+* ``bzr shelve`` can now apply changes without storing anything on the
+ shelf, via the new --destroy option. (Aaron Bentley)
+
+* ``bzr send`` now accepts --body to specify an initial message body.
+ (Aaron bentley)
+
+* ``bzr xxx --usage`` where xxx is a command now shows a usage
+ message and the options without the descriptive help sections
+ (like Description and Examples). A message is also given
+ explaining how to see the complete help, i.e. ``bzr help xxx``.
+ (Ian Clatworthy)
+
+* Content filters can now be used to provide custom conversion
+ between the canonical format of content (i.e. as stored) and
+ the convenience format of content (i.e. as created in working
+ trees). See ``bzr help content-filters`` for further details.
+ (Ian Clatworthy, Alexander Belchenko)
+
+* End-of-line conversion is now supported for formats supporting
+ content filtering. See ``bzr help eol`` for details.
+ (Ian Clatworthy)
+
+* Newly-blessed `join` command allows combining two trees into one.
+ (Aaron Bentley)
+
+Improvements
+************
+
+* A new format name alias ``default-rich-root`` has been added and
+ points at the closest relative of the default format that supports
+ rich roots. (Jelmer Vernooij, #338061)
+
+* Branching from a stacked branch using ``bzr*://`` will now stream
+ the data when the target repository does not need topological
+ ordering, reducing round trips and network overhead. This uses the
+ existing smart server methods added in 1.13, so will work on any
+ 1.13 or newer server. (Robert Collins, Andrew Bennetts)
+
+* ``bzr cat`` and ``bzr export`` now supports a ``--filters`` option
+ that displays/saves the content after content filters are applied.
+ (Ian Clatworthy)
+
+* ``bzr ignore`` gives a more informative message when existing
+ version controlled files match the ignore pattern. (Neil
+ Martinsen-Burrell, #248895)
+
+* ``bzr log`` now has ``--include-merges`` as an alias for ``--levels 0``.
+ (Ian Clatworthy)
+
+* ``bzr send`` is faster on repositories with deep histories.
+ (Ian Clatworthy)
+
+* IPv6 literals are accepted in URLs.
+ (stlman, Martin Pool, Jelmer Vernooij, #165014)
+
+* Progress bars now show the rate of network activity for
+ ``bzr+ssh://`` and ``bzr://`` connections. (Andrew Bennetts)
+
+* Prompt for user names if they are not in the configuration.
+ (Jelmer Vernooij, #256612)
+
+* Pushing to a stacked pack-format branch on a 1.12 or older smart server
+ now takes many less round trips. (Andrew Bennetts, Robert Collins,
+ #294479)
+
+* Streaming push can be done to older repository formats. This is
+ implemented using a new ``Repository.insert_stream_locked`` RPC.
+ (Andrew Bennetts, Robert Collins)
+
+* The "ignoring files outside view: .." message has been re-worded
+ to "Ignoring files outside view. View is .." to reduce confusion
+ about what was being considered and what was being ignored.
+ (Ian Clatworthy)
+
+* The ``long`` log formatter now shows [merge] indicators. If
+ only one level of revisions is displayed and merges are found,
+ the ``long`` and ``short`` log formatters now tell the user
+ how to see the hidden merged revisions. (Ian Clatworthy)
+
+* The ``brisbane-core`` project has delivered its beta format
+ ``development6-rich-root``. This format is suitable for judicious
+ testing by early adopters. In particular if you are benchmarking bzr
+ performance please be sure to test using this format. At this stage
+ more information is best obtained by contacting the Bazaar mailing list
+ or IRC channel if you are interested in using this format. We will make
+ end user documentation available closer to blessing the format as
+ production ready. (Robert Collins, John Arbash Meinel, Ian Clatworthy,
+ Vincent Ladeuil, Andrew Bennetts, Martin Pool)
+
+* Tildes are no longer escaped. No more %7Euser/project/branch!
+ (Jonathan Lange)
+
+Bug Fixes
+*********
+
+* Pushing a new stacked branch will also push the parent inventories for
+ revisions at the stacking boundary. This makes sure that the stacked
+ branch has enough data to calculate inventory deltas for all of its
+ revisions (without requiring the fallback branch). This avoids
+ "'AbsentContentFactory' object has no attribute 'get_bytes_as'" errors
+ when fetching the stacked branch from a 1.13 (or later) smart server.
+ This partially fixes #354036. (Andrew Bennetts, Robert Collins)
+
+* End-Of-Line content filters are now loaded correctly.
+ (Ian Clatworthy, Brian de Alwis, #355280)
+
+* Authentication plugins now receive all the parameters from the request
+ itself (aka host, port, realm, path, etc). Previously, only the
+ authentication section name, username and encoded password were
+ provided. (Jean-Francois Roy)
+
+* bzr gives a better message if an invalid regexp is passed to ``bzr log
+ -m``. (Anne Mohsen, Martin Pool)
+
+* ``bzr split`` now says "See also: join" (Aaron Bentley, #335015)
+
+* ``bzr version-info`` now works in empty branches. (Jelmer Vernooij,
+ #313028)
+
+* Fix "is not a stackable format" error when pushing a
+ stackable-format branch with an unstackable-format repository to a
+ destination with a default stacking policy. (Andrew Bennetts)
+
+* Fixed incorrect "Source format does not support stacking" warning
+ when pushing to a smart server. (Andrew Bennetts, #334114)
+
+* Fix 'make check-dist-tarball' failure by converting paths to unicode when
+ needed. (Vincent Ladeuil, #355454)
+
+* Fixed "Specified file 'x/y/z' is outside current view: " occurring
+ on ``bzr add x/y/z`` in formats supporting views when no view is
+ defined. (Ian Clatworthy, #344708)
+
+* It is no longer possible to fetch between repositories while the
+ target repository is in a write group. This prevents race conditions
+ that prevent the use of RPC's to perform fetch, and thus allows
+ optimising more operations. (Robert Collins, Andrew Bennetts)
+
+* ``merge --force`` works again. (Robert Collins, #342105)
+
+* No more warnings are issued about ``sha`` being deprecated under python-2.6.
+ (Vincent Ladeuil, #346593)
+
+* Pushing a new branch to a server that has a stacking policy will now
+ upgrade from the local branch format when the stacking policy points at
+ a branch which is itself stackable, because we know the client can read
+ both branches, we know that the trunk for the project can be read too,
+ so the upgrade will not inconvenience users. (Robert Collins, #345169)
+
+* Pushing a new stacked branch will also push the parent inventories for
+ revisions at the stacking boundary. This makes sure that the stacked
+ branch has enough data to calculate inventory deltas for all of its
+ revisions (without requiring the fallback branch). This avoids
+ "'AbsentContentFactory' object has no attribute 'get_bytes_as'" errors
+ when fetching the stacked branch from a 1.13 (or later) smart server.
+ This partially fixes #354036. (Andrew Bennetts, Robert Collins)
+
+* The full test suite is passing again on OSX. Several minor issues (mostly
+ test related) have been fixed. (Vincent Ladeuil, #355273).
+
+* The GNU Changelog formatter is slightly improved in the case where
+ the delta is empty, and now correctly claims not to support tags.
+ (Andrea Bolognani)
+
+* Shelve can now shelve changes to a symlink target.
+ (James Westby, #341558)
+
+* The help for the ``info`` command has been corrected.
+ (Ian Clatworthy, #351931)
+
+* Upgrade will now use a sensible default format if the source repository
+ uses rich roots. (Jelmer Vernooij, #252908)
+
+Documentation
+*************
+
+* Expanded the index of the developer documentation. (Eric Siegerman)
+
+* New topic `bzr help debug-flags`. (Martin Pool)
+
+* The generated manpage now explicitly lists aliases as commands.
+ (James Westby, #336998)
+
+API Changes
+***********
+
+* APIs deprecated in 1.6 and previous versions of bzr are now removed.
+ (Martin Pool)
+
+* ``CommitReporter`` is no longer called with ``unchanged`` status during
+ commit - this was a full-tree overhead that bzr no longer performs.
+ (Robert Collins)
+
+* New abstract ``UIFactory`` method ``get_username`` which will be called to
+ obtain the username to use when connecting to remote machines.
+ (Jelmer Vernooij)
+
+* New API ``Inventory.filter()`` added that filters an inventory by
+ a set of file-ids so that only those fileids, their parents and
+ their children are included. (Ian Clatworthy)
+
+* New sort order for ``get_record_stream`` ``groupcompress`` which
+ sorts optimally for use with groupcompress compressors. (John Arbash
+ Meinel, Robert Collins)
+
+* Repository APIs ``get_deltas_for_revisions()`` and
+ ``get_revision_delta()`` now support an optional ``specific_fileids``
+ parameter. If provided, the deltas are filtered so that only those
+ file-ids, their parents and their children are included.
+ (Ian Clatworthy)
+
+* The ``get_credentials`` and ``set_credentials`` methods of
+ ``AuthenticationConfig`` now accept an optional realm argument.
+ (Jean-Francois Roy)
+
+* The ``pb`` argument to ``fetch()`` is deprecated.
+ (Martin Pool)
+
+* The ``Serializer`` class and the serializer ``format registry`` have moved
+ from ``bzrlib.xml_serializer`` to ``bzrlib.serializer``. (Jelmer Vernooij)
+
+* The smart server jail now hooks into BzrDir.open to prevent any BzrDir
+ that is not inside the backing transport from being opened. See the
+ module documentation for ``bzrlib.smart.request`` for details.
+ (Andrew Bennetts, Robert Collins)
+
+* ``Tree.get_symlink_target`` now always returns a unicode string result
+ or None. Previously it would return the bytes from reading the link
+ which could be in any arbitrary encoding. (Robert Collins)
+
+Testing
+*******
+
+* ``bzrlib.tests.TestCase`` now fails the test if its own ``setUp``
+ and ``tearDown`` weren't called. This catches faulty tests that
+ forget to upcall when overriding ``setUp`` and ``tearDown``. Those
+ faulty tests were not properly isolated.
+ (Andrew Bennetts, Robert Collins)
+
+* Fix test_msgeditor.MsgEditorTest test isolation.
+ (Vincent Ladeuil, #347130)
+
+* ``medusa`` is not used anymore as an FTP test server starting with
+ python2.6. A new FTP test server based on ``pyftplib`` can be used
+ instead. This new server is a soft dependency as medusa which is still
+ preferred if both are available (modulo python version).
+ (Vincent Ladeuil)
+
+Internals
+*********
+
+* Added ``chk_map`` for fast, trie-based storage of tuple to string maps.
+ (Robert Collins, John Arbash Meinel, Vincent Ladeuil)
+
+* Added ``bzrlib.chk_map`` for fast, trie-based storage of tuple to string
+ maps. (Robert Collins, John Arbash Meinel, Vincent Ladeuil)
+
+* Added ``bzrlib.inventory_delta`` module. This will be used for
+ serializing and deserializing inventory deltas for more efficient
+ streaming on the network. (Robert Collins, Andrew Bennetts)
+
+* ``Branch._get_config`` has been added, which splits out access to the
+ specific config file from the branch. This is used to let RemoteBranch
+ avoid constructing real branch objects to access configuration settings.
+ (Robert Collins, Andrew Bennetts)
+
+* ``Branch`` now implements ``set_stacked_on_url`` in the base class as
+ the implementation is generic and should impact foreign formats. This
+ helps performance for ``RemoteBranch`` push operations to new stacked
+ branches. (Robert Collins, Andrew Bennetts)
+
+* ``BtreeIndex._spill_mem_keys_to_disk()`` now generates disk index with
+ optmizations turned off. This only has effect when processing > 100,000
+ keys during something like ``bzr pack``. (John Arbash Meinel)
+
+* ``bzr selftest`` now accepts ``--subunit`` to run in subunit output
+ mode. Requires ``lp:subunit`` installed to work, but is not a hard
+ dependency. (Robert Collins)
+
+* ``BzrDir.open_branch`` now takes an optional ``ignore_fallbacks``
+ parameter for controlling opening of stacked branches.
+ (Andrew Bennetts, Robert Collins)
+
+* ``CommitBuilder`` has a new method, ``record_iter_changes`` which works
+ in terms of an iter_changes iterator rather than full tree scanning.
+ (Robert Collins)
+
+* ``DirState`` can now be passed a custom ``SHA1Provider`` object
+ enabling it to store the SHA1 and stat of the canonical (post
+ content filtered) form. (Ian Clatworthy)
+
+* New ``assertLength`` method based on one Martin has squirreled away
+ somewhere. (Robert Collins, Martin Pool)
+
+* New hook ``BzrDir.pre_open`` which runs before opening ``BzrDir``
+ objects, allowing better enforcement of the smart server jail when
+ dealing with stacked branches. (Robert Collins, Andrew Bennetts)
+
+* New hook ``RioVersionInfoBuilder.revision``, allowing extra entries
+ to be added to the stanza that is printed for a particular revision.
+ (Jelmer Vernooij)
+
+* New repository method ``refresh_data`` to cause any repository to
+ make visible data inserted into the repository by a smart server
+ fetch operation. (Robert Collins, Andrew Bennetts)
+
+* ``register_filter_stack_map`` now takes an optional fallback parameter,
+ a callable to invoke if a preference has a value not in the map
+ of filter stacks. This enhancement allows, for example, bzr-svn to
+ handle existing svn properties that define a list of keywords to be
+ expanded. (Ian Clatworthy)
+
+* ``RemoteBranchConfig`` will use a new verb ``Branch.set_config_option``
+ to write config settings to smart servers that support this, saving
+ 5 round trips on the stacked streaming acceptance test.
+ (Robert Collins, Andrew Bennetts)
+
+* ``RemoteBranch`` now provides ``_get_config`` for access to just the
+ branch specific configuration from a remote server, which uses the
+ already existing ``Branch.get_config_file`` smart verb.
+ (Robert Collins, Andrew Bennetts)
+
+* ``RemoteRepository`` will now negatively cache missing revisions during
+ ``get_parent_map`` while read-locked. Write-locks are unaffected.
+ (Robert Collins, Andrew Bennetts)
+
+* Removed ``InterRemoteToOther``, ``InterOtherToRemote`` and
+ ``InterPackToRemotePack`` classes, as they are now unnecessary.
+ (Andrew Bennetts)
+
+* ``RepositoryFormat`` as a new attribute ``fast_deltas`` to indicate
+ whether the repository can efficiently generate deltas between trees
+ regardless of tree size. (Robert Collins)
+
+* ``Repository.iter_files_bytes()`` now properly returns an "iterable of
+ byte strings" (aka 'chunked') for the content. It previously was
+ returning a plain string, which worked, but performed very poorly when
+ building a working tree (file.writelines(str) is very inefficient). This
+ can have a large effect on ``bzr checkout`` times. (John Arbash Meinel)
+
+* selftest now supports a --parallel option, with values of 'fork' or
+ 'subprocess' to run the test suite in parallel. Currently only Linux
+ machines work, other platforms need patches submitted. (Robert Collins,
+ Vincent Ladeuil)
+
+* ``tests.run_suite`` has a new parameter ``suite_decorators``, a list of
+ callables to use to decorate the test suite. Such decorators can add or
+ remove tests, or even remote the test suite to another machine if
+ desired. (Robert Collins)
+
+* The smart server verb ``Repository.get_parent_map`` can now include
+ information about ghosts when the special revision ``include-missing:``
+ is in the requested parents map list. With this flag, ghosts are
+ included as ``missing:REVISION_ID``. (Robert Collins, Andrew Bennetts)
+
+* ``_walk_to_common_revisions`` will now batch up at least 50
+ revisions before calling ``get_parent_map`` on the target,
+ regardless of ``InterRepository``.
+ (Andrew Bennetts, Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
+
diff --git a/doc/en/release-notes/bzr-1.15.txt b/doc/en/release-notes/bzr-1.15.txt
new file mode 100644
index 0000000..7d61cdd
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.15.txt
@@ -0,0 +1,230 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.15
+########
+:1.15rc1: 2009-05-16
+:1.15: 2009-05-22
+:1.15.1: 2009-06-09
+
+The smart server will no longer raise 'NoSuchRevision' when streaming content
+with a size mismatch in a reconstructed graph search. New command ``bzr
+dpush``. Plugins can now define their own annotation tie-breaker when two
+revisions introduce the exact same line.
+
+Changes from 1.15.1 to 1.15.2
+*****************************
+
+* Use zdll on Windows to build ``_chk_map_pyx`` extension.
+ (Alexander Belchenko)
+
+Changes from 1.15final to 1.15.1
+*********************************
+
+* Translate errors received from a smart server in response to a
+ ``BzrDirFormat.initialize`` or ``BzrDirFormat.initialize_ex`` request.
+ This was causing tracebacks even for mundane errors like
+ ``PermissionDenied``. (Andrew Bennetts, #381329)
+
+Changes from 1.15rc1 to 1.15final
+*********************************
+
+* No changes
+
+Compatibility Breaks
+********************
+
+* ``bzr ls`` is no longer recursive by default. To recurse, use the
+ new ``-R`` option. The old ``--non-recursive`` option has been removed.
+ If you alias ``ls`` to ``ls -R``, you can disable recursion using
+ ``--no-recursive`` instead. (Ian Clatworthy)
+
+New Features
+************
+
+* New command ``bzr dpush`` that can push changes to foreign
+ branches (svn, git) without setting custom bzr-specific metadata.
+ (Jelmer Vernooij)
+
+* The new development format ``--development6-rich-root`` now supports
+ stacking. We chose not to use a new format marker, since old clients
+ will just fail to open stacked branches, the same as if we used a new
+ format flag. (John Arbash Meinel, #373455)
+
+* Plugins can now define their own annotation tie-breaker when two revisions
+ introduce the exact same line. See ``bzrlib.annotate._break_annotation_tie``
+ Be aware though that this is temporary, private (as indicated by the leading
+ '_') and a first step to address the problem. (Vincent Ladeuil, #348459)
+
+* New command ``bzr dpush`` that can push changes to foreign
+ branches (svn, git) without setting custom bzr-specific metadata.
+ (Jelmer Vernooij)
+
+* ``bzr send`` will now check the ``child_submit_format`` setting in
+ the submit branch to determine what format to use, if none was
+ specified on the command-line. (Jelmer Vernooij)
+
+Improvements
+************
+
+* -Dhpss output now includes the number of VFS calls made to the remote
+ server. (Jonathan Lange)
+
+* ``--coverage`` works for code running in threads too.
+ (Andrew Bennets, Vincent Ladeuil)
+
+* ``bzr pull`` now has a ``--local`` option to only make changes to the
+ local branch, and not the bound master branch.
+ (Gary van der Merwe, #194716)
+
+* ``bzr rm *`` is now as fast as ``bzr rm * --keep``. (Johan Walles, #180116)
+
+Bug Fixes
+*********
+
+* Adding now works properly when path contains a symbolic link.
+ (Geoff Bache, #183831)
+
+* An error is now raised for unknown eol values. (Brian de Alwis, #358199)
+
+* ``bzr merge --weave`` will now generate a conflict if one side deletes a
+ line, and the other side modifies the line. (John Arbash Meinel, #328171)
+
+* ``bzr reconfigure --standalone`` no longer raises IncompatibleRepositories.
+ (Martin von Gagern, #248932)
+
+* ``bzr send`` works to send emails again using MAPI.
+ (Neil Martinsen-Burrell, #346998)
+
+* Check for missing parent inventories in StreamSink. This prevents
+ incomplete stacked branches being created by 1.13 bzr:// and
+ bzr+ssh:// clients (which have bug #354036). Instead, the server now
+ causes those clients to send the missing records. (Andrew Bennetts)
+
+* Correctly handle HTTP servers proposing multiple authentication schemes.
+ (Vincent Ladeuil, #366107)
+
+* End-Of-Line content filters are now loaded correctly.
+ (Ian Clatworthy, Brian de Alwis, #355280)
+
+* Fix a bug in the pure-python ``GroupCompress`` code when handling copies
+ longer than 64KiB. (John Arbash Meinel, #364900)
+
+* Fix TypeError in running ``bzr break-lock`` on some URLs.
+ (Alexander Belchenko, Martin Pool, #365891)
+
+* Non-recursive ``bzr ls`` now works properly when a path is specified.
+ (Jelmer Vernooij, #357863)
+
+* SSH usernames (defined in ~/.ssh/config) are honoured for bzr+ssh connections.
+ (Vincent Ladeuil, #367726)
+
+* Several bugs related to unicode symlinks have been fixed and the test suite
+ enhanced to better catch regressions for them. (Vincent Ladeuil)
+
+* The smart server will no longer raise 'NoSuchRevision' when streaming
+ content with a size mismatch in a reconstructed graph search: it assumes
+ that the client will make sure it is happy with what it got, and this
+ sort of mismatch is normal for stacked environments.
+ bzr 1.13.0/1 will stream from unstacked branches only - in that case not
+ getting all the content expected would be a bug. However the graph
+ search is how we figured out what we wanted, so a mismatch is both odd
+ and unrecoverable without starting over, and starting over will end up
+ with the same data as if we just permitted the mismatch. If data is
+ gc'd, doing a new search will find only the truncated data, so sending
+ only the truncated data seems reasonable. bzr versions newer than this
+ will stream from stacked branches and check the stream to find missing
+ content in the stacked-on branch, and thus will handle the situation
+ implicitly. (Robert Collins, #360791)
+
+* Upgrading to, or fetching into a 'rich-root' format will now correctly
+ set the root data the same way that reconcile does.
+ (Robert Collins, #368921)
+
+* Using unicode Windows API to obtain command-line arguments.
+ (Alexander Belchenko, #375934)
+
+Documentation
+*************
+
+API Changes
+***********
+
+* ``InterPackRepo.fetch`` and ``RepoFetcher`` now raise ``NoSuchRevision``
+ instead of ``InstallFailed`` when they detect a missing revision.
+ ``InstallFailed`` itself has been deleted. (Jonathan Lange)
+
+* Not passing arguments to ``bzrlib.commands.main()`` will now grab the
+ arguments from ``osutils.get_unicode_argv()`` which has proper support
+ for unicode arguments on windows. Further, the supplied arguments are now
+ required to be unicode strings, rather than user_encoded strings.
+ (Alexander Belchenko)
+
+Internals
+*********
+
+* ``bzrlib.branch.Branch.set_parent`` is now present on the base branch
+ class and will call ``_set_parent_location`` after doing unicode
+ encoding. (Robert Collins)
+
+* ``bzrlib.remote.RemoteBranch._set_parent_location`` will use a new verb
+ ``Branch.set_parent_location`` removing further VFS operations.
+ (Robert Collins)
+
+* ``bzrlib.bzrdir.BzrDir._get_config`` now returns a ``TransportConfig``
+ or similar when the dir supports configuration settings. The base class
+ defaults to None. There is a matching new server verb
+ ``BzrDir.get-config_file`` to reduce roundtrips for getting BzrDir
+ configuration. (Robert Collins)
+
+* ``bzrlib.tests.ExtendedTestResult`` has new methods ``startTests``
+ called before the first test is started, ``done`` called after the last
+ test completes, and a new parameter ``strict``. (Robert Collins)
+
+* ``-Dhpss`` when passed to bzr will cause a backtrace to be printed when
+ VFS operations are started on a smart server repository. This should not
+ occur on regular push and pull operations, and is a key indicator for
+ performance regressions. (Robert Collins)
+
+* ``-Dlock`` when passed to the selftest (e.g. ``bzr -Dlock selftest``) will
+ cause mismatched physical locks to cause test errors rather than just
+ reporting to the screen. (Robert Collins)
+
+* -Dprogress will cause pdb to start up if a progress view jumps
+ backwards. (Robert Collins)
+
+* Fallback ``CredentialStore`` instances registered with ``fallback=True``
+ are now be able to provide credentials if obtaining credentials
+ via ~/.bazaar/authentication.conf fails. (Jelmer Vernooij,
+ Vincent Ladeuil, #321918)
+
+* New hook ``Lock.lock_broken`` which runs when a lock is
+ broken. This is mainly for testing that lock/unlock are
+ balanced in tests. (Vincent Ladeuil)
+
+* New MergeDirective hook 'merge_request_body' allows hooks to supply or
+ alter a body for the message produced by ``bzr send``.
+
+* New smart server verb ``BzrDir.initialize_ex`` which implements a
+ refactoring to the core of clone allowing less round trips on new
+ branches. (Robert Collins)
+
+* New method ``Tags.rename_revisions`` that can rename revision ids tags
+ are pointing at. (Jelmer Vernooij)
+
+* Updated the bundled ``ConfigObj`` library to 4.6.0 (Matt Nordhoff)
+
+Testing
+*******
+
+* ``bzr selftest`` will now fail if lock/unlock are not correctly balanced in
+ tests. Using ``-Dlock`` will turn the related failures into warnings.
+ (Vincent Ladeuil, Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.16.txt b/doc/en/release-notes/bzr-1.16.txt
new file mode 100644
index 0000000..84d31ae
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.16.txt
@@ -0,0 +1,269 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.16.1
+##########
+
+:Released: 2009-06-26
+
+End user testing of the 2a format revealed two serious bugs. The first,
+#365615, caused bzr to raise AbsentContentFactory errors when autopacking.
+This meant that commits or pushes to 2a-format repositories failed
+intermittently.
+
+The second bug, #390563, caused the smart server to raise AbsentContentFactory
+when streaming 2a stacked 2a-format branches. This particularly affected
+branches stored on Launchpad in the 2a format.
+
+Both of these bugs cause command failures only, neither of them cause data
+corruption or data loss. And, of course, both of these bugs are now fixed.
+
+Bug Fixes
+*********
+
+* We now properly request a more minimal set of file texts when fetching
+ multiple revisions. (Robert Collins, John Arbash Meinel, #390563)
+
+* Repositories using CHK pages (which includes the new 2a format) will no
+ longer error during commit or push operations when an autopack operation
+ is triggered. (Robert Collins, #365615)
+
+* ``chk_map.iter_interesting_nodes`` now properly uses the *intersection*
+ of referenced nodes rather than the *union* to determine what
+ uninteresting pages we still need to look at. Prior to this,
+ incrementally pushing to stacked branch would push the minimal data, but
+ fetching everything would request extra texts. There are some unhandled
+ cases wrt trees of different depths, but this fixes the common cases.
+ (Robert Collins, John Arbash Meinel, #390563)
+
+* ``GroupCompress`` repositories now take advantage of the pack hints
+ parameter to permit cross-format fetching to incrementally pack the
+ converted data. (Robert Collins)
+
+* ``Repository.commit_write_group`` now returns opaque data about what
+ was committed, for passing to the ``Repository.pack``. Repositories
+ without atomic commits will still return None. (Robert Collins)
+
+* ``Repository.pack`` now takes an optional ``hint`` parameter
+ which will support doing partial packs for repositories that can do
+ that. (Robert Collins)
+
+* RepositoryFormat has a new attribute 'pack_compresses' which is True
+ when doing a pack operation changes the compression of content in the
+ repository. (Robert Collins)
+
+* ``StreamSink`` and ``InterDifferingSerialiser`` will call
+ ``Repository.pack`` with the hint returned by
+ ``Repository.commit_write_group`` if the formats were different and the
+ repository can increase compression by doing a pack operation.
+ (Robert Collins, #376748)
+
+
+bzr 1.16
+########
+:Codename: yesterday-in-california
+:1.16rc1: 2009-06-11
+:1.16: 2009-06-18
+
+This version of Bazaar contains the beta release of the new ``2a`` repository
+format, suitable for testing by fearless, advanced users. This format or an
+updated version of it will become the default format in Bazaar 2.0. Please
+read the NEWS entry before even thinking about upgrading to the new format.
+
+Also included are speedups for many operations on huge projects, a bug fix for
+pushing stacked new stacked branches to smart servers and the usual bevy of
+bug fixes and improvements.
+
+
+Changes from 1.16rc1 to 1.16final
+*********************************
+
+* Fix the nested tree flag check so that upgrade from development formats to
+ 2a can work correctly.
+ (Jelmer Vernooij, #388727)
+
+* Automatic format upgrades triggered by default stacking policies on a
+ 1.16rc1 (or later) smart server work again.
+ (Andrew Bennetts, #388675)
+
+
+Compatibility Breaks
+********************
+
+* Display prompt on stderr (instead of stdout) when querying users so
+ that the output of commands can be safely redirected.
+ (Vincent Ladeuil, #376582)
+
+
+New Features
+************
+
+* A new repository format ``2a`` has been added. This is a beta release
+ of the brisbane-core (aka group-compress) project. This format now
+ suitable for wider testing by advanced users willing to deal with some
+ bugs. We would appreciate test reports, either positive or negative.
+ Format 2a is substantially smaller and faster for many operations on
+ many trees. This format or an updated version will become the default
+ in bzr 2.0.
+
+ This is a rich-root format, so this repository format can be used with
+ bzr-svn. Bazaar branches in previous non-rich-root formats can be
+ converted (including by merge, push and pull) to format 2a, but not vice
+ versa. We recommend upgrading previous development formats to 2a.
+
+ Upgrading to this format can take considerable time because it expands
+ and more concisely repacks the full history.
+
+ If you use stacked branches, you must upgrade the stacked branches
+ before the stacked-on branches. (See <https://bugs.launchpad.net/bugs/374735>)
+
+* ``--development7-rich-root`` is a new dev format, similar to ``--dev6``
+ but using a Revision serializer using bencode rather than XML.
+ (Jelmer Vernooij, John Arbash Meinel)
+
+* mail_client=claws now supports --body (and message body hooks). Also uses
+ configured from address. (Barry Warsaw)
+
+Improvements
+************
+
+
+* ``--development6-rich-root`` can now stack. (Modulo some smart-server
+ bugs with stacking and non default formats.)
+ (John Arbash Meinel, #373455)
+
+* ``--development6-rich-root`` delays generating a delta index for the
+ first object inserted into a group. This has a beneficial impact on
+ ``bzr commit`` since each committed texts goes to its own group. For
+ committing a 90MB file, it drops peak memory by about 200MB, and speeds
+ up commit from 7s => 4s. (John Arbash Meinel)
+
+* Numerous operations are now faster for huge projects, i.e. those
+ with a large number of files and/or a large number of revisions,
+ particularly when the latest development format is used. These
+ operations (and improvements on OpenOffice.org) include:
+
+ * branch in a shared repository (2X faster)
+ * branch --no-tree (100X faster)
+ * diff (2X faster)
+ * tags (70X faster)
+
+ (Ian Clatworthy)
+
+* Pyrex version of ``bencode`` support. This provides optimized support
+ for both encoding and decoding, and is now found at ``bzrlib.bencode``.
+ ``bzrlib.utils.bencode`` is now deprecated.
+ (Alexander Belchenko, Jelmer Vernooij, John Arbash Meinel)
+
+
+Bug Fixes
+*********
+
+* Bazaar can now pass attachment files to the mutt email client.
+ (Edwin Grubbs, #384158)
+
+* Better message in ``bzr add`` output suggesting using ``bzr ignored`` to
+ see which files can also be added. (Jason Spashett, #76616)
+
+* ``bzr pull -r 123`` from a stacked branch on a smart server no longer fails.
+ Also, the ``Branch.revision_history()`` API now works in the same
+ situation. (Andrew Bennetts, #380314)
+
+* ``bzr serve`` on Windows no longer displays a traceback simply because a
+ TCP client disconnected. (Andrew Bennetts)
+
+* Clarify the rules for locking and fallback repositories. Fix bugs in how
+ ``RemoteRepository`` was handling fallbacks along with the
+ ``_real_repository``. (Andrew Bennetts, John Arbash Meinel, #375496)
+
+* Fix a small bug with fetching revisions w/ ghosts into a new stacked
+ branch. Not often triggered, because it required ghosts to be part of
+ the fetched revisions, not in the stacked-on ancestry.
+ (John Arbash Meinel)
+
+* Fix status and commit to work with content filtered trees, addressing
+ numerous bad bugs with line-ending support. (Ian Clatworthy, #362030)
+
+* Fix problem of "directory not empty" when contending for a lock over
+ SFTP. (Martin Pool, #340352)
+
+* Fix rule handling so that eol is optional, not mandatory.
+ (Ian Clatworthy, #379370)
+
+* Pushing a new stacked branch to a 1.15 smart server was broken due to a
+ bug in the ``BzrDirFormat.initialize_ex`` smart verb. This is fixed in
+ 1.16, but required changes to the network protocol, so the
+ ``BzrDirFormat.initialize_ex`` verb has been removed and replaced with a
+ corrected ``BzrDirFormat.initialize_ex_1.16`` verb. 1.15 clients will
+ still work with a 1.16 server as they will fallback to slower (and
+ bug-free) methods.
+ (Jonathan Lange, Robert Collins, Andrew Bennetts, #385132)
+
+* Reconcile can now deal with text revisions that originated in revisions
+ that are ghosts. (Jelmer Vernooij, #336749)
+
+* Support cloning of branches with ghosts in the left hand side history.
+ (Jelmer Vernooij, #248540)
+
+* The ''bzr diff'' now catches OSError from osutils.rmtree and logs a
+ helpful message to the trace file, unless the temp directory really was
+ removed (which would be very strange). Since the diff operation has
+ succeeded from the user's perspective, no output is written to stderr
+ or stdout. (Maritza Mendez, #363837)
+
+* Translate errors received from a smart server in response to a
+ ``BzrDirFormat.initialize`` or ``BzrDirFormat.initialize_ex`` request.
+ This was causing tracebacks even for mundane errors like
+ ``PermissionDenied``. (Andrew Bennetts, #381329)
+
+Documentation
+*************
+
+* Added directory structure and started translation of docs in Russian.
+ (Alexey Shtokalo, Alexander Iljin, Alexander Belchenko, Dmitry Vasiliev,
+ Volodymyr Kotulskyi)
+
+API Changes
+***********
+
+* Added osutils.parent_directories(). (Ian Clatworthy)
+
+* ``bzrlib.progress.ProgressBar``, ``ChildProgress``, ``DotsProgressBar``,
+ ``TTYProgressBar`` and ``child_progress`` are now deprecated; use
+ ``ui_factory.nested_progress_bar`` instead. (Martin Pool)
+
+* ``graph.StackedParentsProvider`` is now a public API, replacing
+ ``graph._StackedParentsProvider``. The api is now considered stable and ready
+ for external users. (Gary van der Merwe)
+
+* ``bzrlib.user_encoding`` is deprecated in favor of
+ ``get_user_encoding``. (Alexander Belchenko)
+
+* TreeTransformBase no longer assumes that limbo is provided via disk.
+ DiskTreeTransform now provides disk functionality. (Aaron Bentley)
+
+Internals
+*********
+
+* Remove ``weave.py`` script for accessing internals of old weave-format
+ repositories. (Martin Pool)
+
+Testing
+*******
+
+* ``make check`` no longer repeats the test run in ``LANG=C``.
+ (Martin Pool, #386180)
+
+* The number of cores is now correctly detected on OSX. (John Szakmeister)
+
+* The number of cores is also detected on Solaris and win32. (Vincent Ladeuil)
+
+* The number of cores is also detected on FreeBSD. (Matthew Fuller)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.17.txt b/doc/en/release-notes/bzr-1.17.txt
new file mode 100644
index 0000000..c4180cd
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.17.txt
@@ -0,0 +1,259 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.17
+########
+:Codename: so-late-its-brunch
+:1.17rc1: 2009-07-13
+:1.17: 2009-07-20
+
+
+Bazaar continues to blaze a straight and shining path to the 2.0 release and
+the elevation of the ``2a`` beta format to the full glory of "supported and
+stable".
+
+Highlights in this release include greatly reduced memory consumption during
+commits, faster ``ls``, faster ``annotate``, faster network operations if
+you're specifying a revision number and the final destruction of those
+annoying progress bar artifacts.
+
+
+Changes from 1.17rc1 to 1.17final
+*********************************
+
+* Change an extension to call the python ``frozenset()`` rather than the C
+ api ``PyFrozenSet_New``. It turns out that python2.4 did not expose the
+ C api. (John Arbash Meinel, #399366)
+
+* Fixes for the Makefile and the rename of ``generate_docs.py`` to
+ ``tools/generate_docs.py`` to allow everything to be built on Windows.
+ (John Arbash Meinel, #399356)
+
+* ``bzr serve`` once again applies a ``ChrootServer`` to the given
+ directory before serving it. (Andrew Bennetts, #400535)
+
+
+Compatibility Breaks
+********************
+
+* ``bzr register-branch`` from the Launchpad plugin now refers to "project"
+ instead of "product" which is the correct Launchpad terminology. The
+ --product option is deprecated and users should switch to using --project.
+ (Neil Martinsen-Burrell, #238764)
+
+
+New Features
+************
+
+* ``bzr push`` now aborts if uncommitted changes (including pending merges)
+ are present in the working tree (if one is present) and no revision is
+ specified. The configuration option ``push_strict`` can be used to set the
+ default for this behavior. (Vincent Ladeuil, #284038, #322808, #65286)
+
+* ``bzr revno`` and ``bzr revision-info`` now have a ``--tree`` option to
+ show revision info for the working tree instead of the branch.
+ (Matthew Fuller, John Arbash Meinel)
+
+* ``bzr send`` now aborts if uncommitted changes (including pending merges)
+ are present in the working tree and no revision is specified. The
+ configuration option ``send_strict`` can be used to set the default for this
+ behavior.
+ (Vincent Ladeuil, #206577)
+
+* ``bzr switch --create-branch/-b`` can now be used to create and switch
+ to a new branch. Supplying a name without a ``/`` will create the branch
+ relative to the existing branch. (similar to how ``bzr switch name``
+ works when the branch already exists.) (John Arbash Meinel)
+
+
+Bug Fixes
+*********
+
+* Accept uppercase "Y/N" to prompts such as from break lock.
+ (#335182, Tim Powell, Martin Pool)
+
+* Add documentation about diverged branches and how to fix them in the
+ centralized workflow with local commits. Mention ``bzr help
+ diverged-branches`` when a push fails because the branches have
+ diverged. (Neil Martinsen-Burrell, #269477)
+
+* Annotate would sometimes 'latch on' to trivial lines, causing important
+ lines to be incorrectly annotated. (John Arbash Meinel, #387952)
+
+* Automatic format upgrades triggered by default stacking policies on a
+ 1.16rc1 (or later) smart server work again.
+ (Andrew Bennetts, #388675)
+
+* Avoid progress bar artifacts being left behind on the screen.
+ (Martin Pool, #321935)
+
+* Better message in ``bzr split`` error suggesting a rich root format.
+ (Neil Martinsen-Burrell, #220067)
+
+* ``Branch.set_append_revisions_only`` now works with branches on a smart
+ server. (Andrew Bennetts, #365865)
+
+* By default, ``bzr branch`` will fail if the target directory exists, but
+ does not already have a control directory. The flag ``--use-existing-dir``
+ will allow operation to proceed. (Alexander Belchenko, #307554)
+
+* ``bzr ls DIR --from-root`` now shows only things in DIR, not everything.
+ (Ian Clatworthy)
+
+* Fetch between repositories does not error if they have inconsistent data
+ that should be irrelevant to the fetch operation. (Aaron Bentley)
+
+* Fix ``AttributeError`` exception when reconfiguring lightweight checkout
+ of a remote repository.
+ (Jelmer Vernooij, #332194)
+
+* Fix bug in decoding v3 smart server messages when receiving multiple
+ lots of excess bytes after an end-of-message.
+ (Andrew Bennetts)
+
+* Force deletion of readonly files during merge, update and other tree
+ transforms.
+ (Craig Hewetson, Martin Pool, #218206)
+
+* Force socket shutdown in threaded HTTP test servers to avoid client hangs
+ (pycurl). (Vincent Ladeuil, #383920).
+
+* ``LRUCache`` will maintain the linked list pointers even if a nodes
+ cleanup function raises an exception. (John Arbash Meinel, #396838)
+
+* Progress bars are now suppressed again when the environment variable
+ ``BZR_PROGRESS_BAR`` is set to ``none``.
+ (Martin Pool, #339385)
+
+* Reduced memory consumption during ``bzr commit`` of large files. For
+ pre 2a formats, should be down to ~3x the size of a file.
+ For ``--2a`` format repositories, it is down to the size of the file
+ content plus the size of the compressed text. Related to bug #109114.
+ (John Arbash Meinel)
+
+* Set hidden attribute on .bzr directory below unicode path should never
+ fail with error. The operation should succeed even if bzr unable to set
+ the attribute. (Alexander Belchenko, related to bug #335362).
+
+* Stacking will no longer accept requests to stack on the same
+ branch/repository. Existing branches that incorrectly reference the same
+ repository in a stacking configuration will now raise
+ UnstackableLocationError when the branch is opened. This can be fixed by
+ removing the stacking location inside ``.bzr/branch``.
+ (Robert Collins, #376243)
+
+* The ``log+`` decorator, useful in debugging or profiling, could cause
+ "AttributeError: 'list' object has no attribute 'next'". This is now
+ fixed. The log decorator no longer shows the elapsed time or transfer
+ rate because they're available in the log prefixes and the transport
+ activity display respectively.
+ (Martin Pool, #340347)
+
+* Unshelve works correctly when multiple zero-length files are present on
+ the shelf. (Aaron Bentley, #363444)
+
+* Progress bars no longer show the network transport scheme or direction.
+ (Martin Pool)
+
+* launchpad-login now respects the 'verbose' option.
+ (Jonathan Lange, #217031)
+
+
+Internals
+*********
+
+* ``bzrlib.user_encoding`` is now officially deprecated. It is not
+ possible to write a deprecation wrapper, but the variable will be
+ removed in the near future. Use ``bzrlib.osutils.get_user_encoding()``
+ instead. (Alexander Belchenko)
+
+* Command lookup has had hooks added. ``bzrlib.Command.hooks`` has
+ three new hook points: ``get_command``, ``get_missing_command`` and
+ ``list_commands``, which allow just-in-time command name provision
+ rather than requiring all command names be known a-priori.
+ (Robert Collins)
+
+* ``get_app_path`` from win32utils.py now supports REG_EXPAND_SZ data type
+ and can read path to wordpad.exe. (Alexander Belchenko, #392046)
+
+* ``graph.KnownGraph`` has been added. This is a class that can give
+ answers to ``heads()`` very quickly. However, it has the assumption that
+ the whole graph has already been loaded. This is true during
+ ``annotate`` so it is used there with good success (as much as 2x faster
+ for files with long ancestry and 'cherrypicked' changes.)
+ (John Arbash Meinel, Vincent Ladeuil)
+
+* OS file locks are now taken out using ``CreateFile`` rather than
+ ``LockFileEx`` on Windows. The locking remains exclusive with
+ ``LockFileEx`` but now it also works on older versions of Windows (such
+ as Win98). (Martin <gzlist>)
+
+* pack <=> pack fetching is now done via a ``PackStreamSource`` rather
+ than the ``Packer`` code. The user visible change is that we now
+ properly fetch the minimum number of texts for non-smart fetching.
+ (John Arbash Meinel)
+
+
+* ``VersionedFiles._add_text`` is a new api that lets us insert text into
+ the repository as a single string, rather than a list of lines. This can
+ improve memory overhead and performance of committing large files.
+ (Currently a private api, used only by commit). (John Arbash Meinel)
+
+
+Improvements
+************
+
+* ``bzr annotate`` can now be significantly faster. The time for
+ ``bzr annotate NEWS`` is down to 7s from 22s in 1.16. Files with long
+ histories and lots of 'duplicate insertions' will be improved more than
+ others. (John Arbash Meinel, Vincent Ladeuil)
+
+* ``bzr ls`` is now faster. On OpenOffice.org, the time drops from 2.4
+ to 1.1 seconds. The improvement for ``bzr ls -r-1`` is more
+ substantial dropping from 54.3 to 1.1 seconds. (Ian Clatworthy)
+
+* Improve "Path(s) are not versioned" error reporting for some commands.
+ (Benoît PIERRE)
+
+* Initial commit performance in ``--2a`` repositories has been improved by
+ making it cheaper to build the initial CHKMap. (John Arbash Meinel)
+
+* Resolving a revno to a revision id on a branch accessed via ``bzr://``
+ or ``bzr+ssh://`` is now much faster and involves no VFS operations.
+ This speeds up commands like ``bzr pull -r 123``. (Andrew Bennetts)
+
+* ``revision-info`` now properly aligns the revnos/revids in the output
+ and doesn't traceback when given revisions not in the current branch.
+ Performance is also significantly improved when requesting multiple revs
+ at once. (Matthew Fuller, John Arbash Meinel)
+
+* Tildes are no longer escaped by Transports. (Andy Kilner)
+
+
+Documentation
+*************
+
+* Avoid bad text wrapping in generated documentation. Slightly better
+ formatting in the user reference.
+ (Martin Pool, #249908)
+
+* Minor clarifications to the help for End-Of-Line conversions.
+ (Ian Clatworthy)
+
+API Changes
+***********
+
+* Removed overspecific error class ``InvalidProgressBarType``.
+ (Martin Pool)
+
+* The method ``ProgressView._show_transport_activity`` is now
+ ``show_transport_activity`` because it's part of the contract between
+ this class and the UI. (Martin Pool)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.18.txt b/doc/en/release-notes/bzr-1.18.txt
new file mode 100644
index 0000000..6a50b4a
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.18.txt
@@ -0,0 +1,393 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.18.1
+##########
+
+:Codename: nein nein nein!
+:1.18.1: 2009-09-09
+
+This release fixes two small but worthwhile bugs relevant to users on
+Microsoft Windows: some commands that failed on with locking errors will
+now work, and a bug that caused poor performance after committing a file
+with line-ending conversion has now been fixed. It also fixes a bug in
+pushing to older servers.
+
+Bug Fixes
+*********
+
+* Fixed a problem where using content filtering and especially end-of-line
+ conversion will commit too many copies a file.
+ (Martin Pool, #415508)
+
+* Fix assertion error about ``_remember_remote_is_before`` in
+ ``set_tags_bytes`` when pushing to older smart servers.
+ (Andrew Bennetts, Alexander Belchenko, #418931)
+
+Improvements
+************
+
+* ``bzr push`` locally on Windows will no longer give a locking error with
+ dirstate based formats. (Robert Collins)
+
+* ``bzr shelve`` and ``bzr unshelve`` now work on Windows.
+ (Robert Collins, #305006)
+
+API Changes
+***********
+
+* ``bzrlib.shelf_ui`` has had the ``from_args`` convenience methods of its
+ classes changed to manage lock lifetime of the trees they open in a way
+ consistent with reader-exclusive locks. (Robert Collins, #305006)
+
+* ``Tree.path_content_summary`` may return a size of None, when called on
+ a tree with content filtering where the size of the canonical form
+ cannot be cheaply determined. (Martin Pool)
+
+* When manually creating transport servers in test cases, a new helper
+ ``TestCase.start_server`` that registers a cleanup and starts the server
+ should be used. (Robert Collins)
+
+bzr 1.18
+########
+
+Compatibility Breaks
+********************
+
+* Committing directly to a stacked branch from a lightweight checkout will
+ no longer work. In previous versions this would appear to work but would
+ generate repositories with insufficient data to create deltas, leading
+ to later errors when branching or reading from the repository.
+ (Robert Collins, bug #375013)
+
+New Features
+************
+
+Bug Fixes
+*********
+
+* Fetching from 2a branches from a version-2 bzr protocol would fail to
+ copy the internal inventory pages from the CHK store. This cannot happen
+ in normal use as all 2a compatible clients and servers support the
+ version-3 protocol, but it does cause test suite failures when testing
+ downlevel protocol behaviour. (Robert Collins)
+
+* Fix a test failure on karmic by making a locale test more robust.
+ (Vincent Ladeuil, #413514)
+
+* Fixed "Pack ... already exists" error when running ``bzr pack`` on a
+ fully packed 2a repository. (Andrew Bennetts, #382463)
+
+* Further tweaks to handling of ``bzr add`` messages about ignored files.
+ (Jason Spashett, #76616)
+
+* Properly handle fetching into a stacked branch while converting the
+ data, especially when there are also ghosts. The code was filling in
+ parent inventories incorrectly, and also not handling when one of the
+ parents was a ghost. (John Arbash Meinel, #402778, #412198)
+
+* ``RemoteStreamSource.get_stream_for_missing_keys`` will fetch CHK
+ inventory pages when appropriate (by falling back to the vfs stream
+ source). (Andrew Bennetts, #406686)
+
+* StreamSource generates rich roots from non-rich root sources correctly
+ now. (Andrew Bennetts, #368921)
+
+* When deciding whether a repository was compatible for upgrading or
+ fetching, we previously incorrectly checked the default repository
+ format for the bzrdir format, rather than the format that was actually
+ present on disk. (Martin Pool, #408824)
+
+Improvements
+************
+
+* A better description of the platform is shown in crash tracebacks, ``bzr
+ --version`` and ``bzr selftest``.
+ (Martin Pool, #409137)
+
+* Cross-format fetches (such as between 1.9-rich-root and 2a) via the
+ smart server are more efficient now. They send inventory deltas rather
+ than full inventories. The smart server has two new requests,
+ ``Repository.get_stream_1.19`` and ``Repository.insert_stream_1.19`` to
+ support this. (Andrew Bennetts, #374738, #385826)
+
+* Extracting the full ancestry and computing the ``merge_sort`` is now
+ significantly faster. This effects things like ``bzr log -n0``. (For
+ example, ``bzr log -r -10..-1 -n0 bzr.dev`` is 2.5s down to 1.0s.
+ (John Arbash Meinel)
+
+Documentation
+*************
+
+API Changes
+***********
+
+Internals
+*********
+
+* ``-Dstrict_locks`` can now be used to check that read and write locks
+ are treated properly w.r.t. exclusivity. (We don't try to take an OS
+ read lock on a file that we already have an OS write lock on.) This is
+ now set by default for all tests, if you have a test which cannot be
+ fixed, you can use ``self.thisFailsStrictLockCheck()`` as a
+ compatibility knob. (John Arbash Meinel)
+
+* InterDifferingSerializer is now only used locally. Other fetches that
+ would have used InterDifferingSerializer now use the more network
+ friendly StreamSource, which now automatically does the same
+ transformations as InterDifferingSerializer. (Andrew Bennetts)
+
+* ``KnownGraph`` now has a ``.topo_sort`` and ``.merge_sort`` member which
+ are implemented in pyrex and significantly faster. This is exposed along
+ with ``CombinedGraphIndex.find_ancestry()`` as
+ ``VersionedFiles.get_known_graph_ancestry(keys)``.
+ (John Arbash Meinel)
+
+* RemoteBranch.open now honours ignore_fallbacks correctly on bzr-v2
+ protocols. (Robert Collins)
+
+* The index code now has some specialized routines to extract the full
+ ancestry of a key in a more efficient manner.
+ ``CombinedGraphIndex.find_ancestry()``. (Time to get ancestry for
+ bzr.dev drops from 1.5s down to 300ms. For OOo from 33s => 10.5s) (John
+ Arbash Meinel)
+
+Testing
+*******
+
+* Install the test ssl certificate and key so that installed bzr
+ can run the https tests. (Denys Duchier, #392401)
+
+
+bzr 1.18rc1
+###########
+
+:Codename: little traveller
+:1.18: 2009-08-20
+:1.18rc1: 2009-08-10
+
+This release of Bazaar marches on towards the 2.0 release in which the 2a
+'brisbane-core' format becomes generally recommended. Most of the work in
+this release now focusses on bug fixes and stabilization, covering both 2a
+and previous formats. There is a new text-mode interactive merge feature,
+a new guide to migration to 2a format in the user documentation, and
+pushing branches to a smart server is now much faster.
+
+The Bazaar team decided that 2.0 will be a long-term supported release,
+with bugfix-only releases based on it continuing for at least six months
+or until the following stable release.
+
+There are no changes from 1.18rc1 to 1.18.
+
+New Features
+************
+
+* ``bzr merge --interactive`` applies a user-selected portion of the
+ merge. The UI is similar to ``shelve``. (Aaron Bentley)
+
+* ``bzr reconfigure`` now takes options ``--stacked-on URL`` and
+ ``--unstacked`` to change stacking of a branch.
+ (Martin Pool, #391411)
+
+Bug Fixes
+*********
+
+* Annotating on a stacked branch will now succeed in simple scenarios.
+ There are still some complex scenarios where it will fail (bug #399884)
+ (John Arbash Meinel, #393366)
+
+* A progress bar is no longer left dangling when ``bzr selftest``
+ completes, and the progress bar updates with zero latency so the
+ displayed test name is always the one that's actually running.
+ (Martin Pool, #123688)
+
+* Authenticating against an SSH server now uses ``auth_none`` to determine
+ if password authentication is even supported. This fixes a bug where
+ users would be prompted for a launchpad password, even though launchpad
+ only supports publickey authentication. (John Arbash Meinel, #375867)
+
+* BranchBuilder now accepts timezone to avoid test failures in countries far
+ from GMT. (Vincent Ladeuil, #397716)
+
+* ``bzr commit`` no longer saves the unversioning of missing files until
+ the commit has completed on the branch. This means that aborting a
+ commit that found a missing file will leave the tree unedited.
+ (Robert Collins, #282402)
+
+* ``bzr mv`` no longer takes out branch locks, which allows it to work
+ when the branch is readonly. (Robert Collins, #216541)
+
+* ``bzr revert .`` no longer generates an InconsistentDelta error when
+ there are missing subtrees. (Robert Collins, #367632)
+
+* ``bzr send`` now generates valid bundles with ``--2a`` formats. However,
+ do to internal changes necessary to support this, older clients will
+ fail when trying to insert them. For newer clients, the bundle can be
+ used to apply the changes to any rich-root compatible format.
+ (John Arbash Meinel, #393349)
+
+* Cope with FTP servers that don't support restart/append by falling back
+ to reading and then rewriting the whole file, such as TahoeLAFS. (This
+ fallback may be slow for some access patterns.) (Nils Durner, #294709)
+
+* Encode the paths in ``mbcs`` encoding on Windows when spawning an
+ external diff client. This at least allows supporting filenames that are
+ not ascii, but are present in the current locale. Ideally we would be
+ able to pass the Unicode path, but that would be client dependent.
+ (John Arbash Meinel, #382709)
+
+* Fix a compile bug on Solaris having to do with const and
+ pointer-to-pointers. (John Arbash Meinel, #408441)
+
+* Fixed a NameError that occurs when merging or pulling from a URL that
+ causes a redirection loop when bzr tries to read a URL as a bundle.
+ (Andrew Bennetts, #400847)
+
+* Fix ``AttributeError: 'TestUIFactory' object has no attribute 'tick'``
+ running send and similar commands on 2a formats.
+ (Martin Pool, #408201)
+
+* Fix crash in some invocations of ``bzr status`` in format 2a.
+ (Martin Pool, #403523)
+
+* Fixed export to existing directory: if directory is empty then export
+ will succeed, otherwise it fails with error.
+ (Alexander Belchenko, #406174)
+
+* Fixed spurious "Source branch does not support stacking" warning when
+ pushing. (Andrew Bennetts, #388908)
+
+* Fixed spurious transport activity indicator appearing while tests are
+ running. (Martin Pool, #343532)
+
+* Merge now correctly handles empty right-hand revision specs.
+ (Aaron Bentley, #333961)
+
+* Renames to lexographically lower basenames in trees that have never been
+ committed to will no longer corrupt the dirstate. This was caused by an
+ bug in the dirstate update_minimal method. (Robert Collins, #395556)
+
+* Requests for unknown methods no longer cause the smart server to log
+ lots of backtraces about ``UnknownSmartMethod``, ``do_chunk`` or
+ ``do_end``. (Andrew Bennetts, #338561)
+
+* Shelve will not shelve the initial add of the tree root. (Aaron Bentley)
+
+* Streaming from bzr servers where there is a chain of stacked branches
+ (A stacked on B stacked on C) will now work. (Robert Collins, #406597)
+
+* The environment variable ``BZR_PROGRESS_BAR`` set to either ``text`` or ``none``
+ always forces progress bars either on or off respectively. Otherwise,
+ they're turned on if ``TERM`` is not ``dumb`` and stderr is a terminal.
+ bzr always uses the 'text' user interface when run as a command, so
+ ``BZR_USE_TEXT_UI`` is no longer needed.
+ (Martin Pool, #339385, #387717)
+
+* The optional ``_knit_load_data_pyx`` C extension was never being
+ imported. This caused significant slowdowns when reading data from
+ repositories. (Andrew Bennetts, #405653)
+
+* The ``--hardlink`` option to ``branch`` and ``checkout`` is not
+ supported at the moment on workingtree formats that can do content
+ filtering. (See <https://bugs.launchpad.net/bzr/+bug/408193>.)
+ bzr now says so, rather than just ignoring the option. (Martin Pool)
+
+* There was a bug in ``osutils.relpath`` that was only triggered on
+ Windows. Essentially if you were at the root of a drive, and did
+ something to a branch/repo on another drive, we would go into an
+ infinite loop while trying to find a 'relative path'.
+ (John Arbash Meinel, #394227)
+
+* ``WorkingTree4.unversion`` will no longer fail to unversion ids which
+ were present in a parent tree but renamed in the working tree.
+ (Robert Collins, #187207)
+
+Improvements
+************
+
+* Can now rename/move files even if they have been removed from the inventory.
+ (Marius Kruger)
+
+* Pushing branches with tags via ``bzr://`` and ``bzr+ssh://`` is much
+ faster, using a new ``Branch.set_tags_bytes`` smart server verb rather
+ than VFS methods. For example, pushes of small branches with tags take
+ 11 rather than 18 smart server requests. (Andrew Bennetts, #398608)
+
+* Sending Ctrl-Break on Windows will now drop you into the debugger, in
+ the same way that sending Ctrl-\\ does on other platforms.
+ (John Arbash Meinel)
+
+Documentation
+*************
+
+* Added Bazaar 2.0 Upgrade Guide. (Ian Clatworthy)
+
+API Changes
+***********
+
+* ``CLIUIFactory`` is deprecated; use ``TextUIFactory`` instead if you
+ need to subclass or create a specific class, or better yet the existing
+ ``make_ui_for_terminal``. ``SilentUIFactory`` is clarified to do no
+ user interaction at all, rather than trying to read from stdin but not
+ writing any output, which would be strange if reading prompts or
+ passwords. (Martin Pool)
+
+* New TransformPreview.commit() allows committing without a working tree.
+ (Aaron Bentley)
+
+* ``pb`` parameter to ``TextTestResult`` is deprecated and ignored.
+ (Martin Pool)
+
+* ProgressTasks now prefer to talk direct to their ProgressView not to the
+ UIFactory.
+ (Martin Pool)
+
+* ``WorkingTree._check`` now requires a references dict with keys matching
+ those returned by ``WorkingTree._get_check_refs``. (Robert Collins)
+
+Internals
+*********
+
+* ``CHKInventory.path2id`` uses the parent_id to basename hash to avoid
+ reading the entries along the path, reducing work to lookup ids from
+ paths. (Robert Collins)
+
+* ``CHKMap.apply_delta`` now raises ``InconsistentDelta`` if a delta adds
+ as new a key which was already mapped. (Robert Collins)
+
+* Inventory delta application catches more cases of corruption and can
+ prevent corrupt deltas from affecting consistency of data structures on
+ disk. (Robert Collins)
+
+* --subunit support now adds timestamps if the subunit version supports
+ it. (Robert Collins)
+
+* The Windows all-in-one installer now bundles the PyQt image format
+ plugins, which allows previewing more images as part of 'qdiff'.
+ (Alexander Belchenko)
+
+
+Testing
+*******
+
+* Merge directive cherrypick tests must use the same root id.
+ (Martin Pool, #409684)
+
+* Spurious failure in ``check`` tests on rich-root formats fixed.
+ (Martin Pool, #408199)
+
+* The ``bzrlib.tests.TextTestRunner`` will no longer call
+ ``countTestsCases`` on the test being run. Progress information is
+ instead handled by having the test passed in call ``result.progress``
+ before running its contents. This improves the behaviour when using
+ ``TextTestRunner`` with test suites that don't support
+ ``countTestsCases``. (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
+
diff --git a/doc/en/release-notes/bzr-1.2.txt b/doc/en/release-notes/bzr-1.2.txt
new file mode 100644
index 0000000..08a3f34
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.2.txt
@@ -0,0 +1,224 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.2
+#######
+
+:Released: 2008-02-15
+
+Bug Fixes
+*********
+
+* Fix failing test in Launchpad plugin. (Martin Pool)
+
+
+bzr 1.2rc1
+##########
+
+:Released: 2008-02-13
+
+Notes When Upgrading
+********************
+
+* Fetching via the smart protocol may need to reconnect once during a fetch
+ if the remote server is running Bazaar 1.1 or earlier, because the client
+ attempts to use more efficient requests that confuse older servers. You
+ may be required to re-enter a password or passphrase when this happens.
+ This won't happen if the server is upgraded to Bazaar 1.2.
+ (Andrew Bennetts)
+
+Changes
+*******
+
+* Fetching via bzr+ssh will no longer fill ghosts by default (this is
+ consistent with pack-0.92 fetching over SFTP). (Robert Collins)
+
+* Formatting of ``bzr plugins`` output is changed to be more human-
+ friendly. Full path of plugins locations will be shown only with
+ ``--verbose`` command-line option. (Alexander Belchenko)
+
+* ``merge`` now prefers to use the submit branch, but will fall back to
+ parent branch. For many users, this has no effect. But some users who
+ pull and merge on the same branch will notice a change. This change
+ makes it easier to work on a branch on two different machines, pulling
+ between the machines, while merging from the upstream.
+ ``merge --remember`` can now be used to set the submit_branch.
+ (Aaron Bentley)
+
+Features
+********
+
+* ``merge --preview`` produces a diff of the changes merge would make,
+ but does not actually perform the merge. (Aaron Bentley)
+
+* New smart method ``Repository.get_parent_map`` for getting revision
+ parent data. This returns additional parent information topologically
+ adjacent to the requested data to reduce round trip latency impacts.
+ (Robert Collins)
+
+* New smart method, ``Repository.stream_revisions_chunked``, for fetching
+ revision data that streams revision data via a chunked encoding. This
+ avoids buffering large amounts of revision data on the server and on the
+ client, and sends less data to the server to request the revisions.
+ (Andrew Bennetts, Robert Collins, #178353)
+
+* The launchpad plugin now handles lp URLs of the form
+ ``lp://staging/``, ``lp://demo/``, ``lp://dev/`` to use the appropriate
+ launchpad instance to do the resolution of the branch identities.
+ This is primarily of use to Launchpad developers, but can also
+ be used by other users who want to try out Launchpad as
+ a branch location without messing up their public Launchpad
+ account. Branches that are pushed to the staging environment
+ have an expected lifetime of one day. (Tim Penhey)
+
+Improvements
+************
+
+* Creating a new branch no longer tries to read the entire revision-history
+ unnecessarily over smart server operations. (Robert Collins)
+
+* Fetching between different repository formats with compatible models now
+ takes advantage of the smart method to stream revisions. (Andrew Bennetts)
+
+* The ``--coverage`` option is now global, rather specific to ``bzr
+ selftest``. (Andrew Bennetts)
+
+* The ``register-branch`` command will now use the public URL of the branch
+ containing the current directory, if one has been set and no explicit
+ branch is provided. (Robert Collins)
+
+* Tweak the ``reannotate`` code path to optimize the 2-parent case.
+ Speeds up ``bzr annotate`` with a pack repository by approx 3:2.
+ (John Arbash Meinel)
+
+Bugfixes
+********
+
+* Calculate remote path relative to the shared medium in _SmartClient. This
+ is related to the problem in bug #124089. (Andrew Bennetts)
+
+* Cleanly handle connection errors in smart protocol version two, the same
+ way as they are handled by version one. (Andrew Bennetts)
+
+* Clearer error when ``version-info --custom`` is used without
+ ``--template`` (Lukáš Lalinský)
+
+* Don't raise UnavailableFeature during test setup when medusa is not
+ available or tearDown is never called leading to nasty side effects.
+ (#137823, Vincent Ladeuil)
+
+* If a plugin's test suite cannot be loaded, for example because of a syntax
+ error in the tests, then ``selftest`` fails, rather than just printing
+ a warning. (Martin Pool, #189771)
+
+* List possible values for BZR_SSH environment variable in env-variables
+ help topic. (Alexander Belchenko, #181842)
+
+* New methods ``push_log_file`` and ``pop_log_file`` to intercept messages:
+ popping the log redirection now precisely restores the previous state,
+ which makes it easier to use bzr log output from other programs.
+ TestCaseInTempDir no longer depends on a log redirection being established
+ by the test framework, which lets bzr tests cleanly run from a normal
+ unittest runner.
+ (#124153, #124849, Martin Pool, Jonathan Lange)
+
+* ``pull --quiet`` is now more quiet, in particular a message is no longer
+ printed when the remembered pull location is used. (James Westby,
+ #185907)
+
+* ``reconfigure`` can safely be interrupted while fetching.
+ (Aaron Bentley, #179316)
+
+* ``reconfigure`` preserves tags when converting to and from lightweight
+ checkouts. (Aaron Bentley, #182040)
+
+* Stop polluting /tmp when running selftest.
+ (Vincent Ladeuil, #123363)
+
+* Switch from NFKC => NFC for normalization checks. NFC allows a few
+ more characters which should be considered valid.
+ (John Arbash Meinel, #185458)
+
+* The launchpad plugin now uses the ``edge`` XML-RPC server to avoid
+ interacting badly with a bug on the launchpad side. (Robert Collins)
+
+* Unknown hostnames when connecting to a ``bzr://`` URL no longer cause
+ tracebacks. (Andrew Bennetts, #182849)
+
+API Breaks
+**********
+
+* Classes implementing Merge types like Merge3Merger must now accept (and
+ honour) a do_merge flag in their constructor. (Aaron Bentley)
+
+* ``Repository.add_inventory`` and ``add_revision`` now require the caller
+ to previously take a write lock (and start a write group.)
+ (Martin Pool)
+
+Testing
+*******
+
+* selftest now accepts --load-list <file> to load a test id list. This
+ speeds up running the test suite on a limited set of tests.
+ (Vincent Ladeuil)
+
+Internals
+*********
+
+* Add a new method ``get_result`` to graph search objects. The resulting
+ ``SearchResult`` can be used to recreate the search later, which will
+ be useful in reducing network traffic. (Robert Collins)
+
+* Use convenience function to check whether two repository handles
+ are referring to the same repository in ``Repository.get_graph``.
+ (Jelmer Vernooij, #187162)
+
+* Fetching now passes the find_ghosts flag through to the
+ ``InterRepository.missing_revision_ids`` call consistently for all
+ repository types. This will enable faster missing revision discovery with
+ bzr+ssh. (Robert Collins)
+
+* Fix error handling in Repository.insert_data_stream. (Lukas Lalinsky)
+
+* ``InterRepository.missing_revision_ids`` is now deprecated in favour of
+ ``InterRepository.search_missing_revision_ids`` which returns a
+ ``bzrlib.graph.SearchResult`` suitable for making requests from the smart
+ server. (Robert Collins)
+
+* New error ``NoPublicBranch`` for commands that need a public branch to
+ operate. (Robert Collins)
+
+* New method ``iter_inventories`` on Repository for access to many
+ inventories. This is primarily used by the ``revision_trees`` method, as
+ direct access to inventories is discouraged. (Robert Collins)
+
+* New method ``next_with_ghosts`` on the Graph breadth-first-search objects
+ which will split out ghosts and present parents into two separate sets,
+ useful for code which needs to be aware of ghosts (e.g. fetching data
+ cares about ghosts during revision selection). (Robert Collins)
+
+* Record a timestamp against each mutter to the trace file, relative to the
+ first import of bzrlib. (Andrew Bennetts)
+
+* ``Repository.get_data_stream`` is now deprecated in favour of
+ ``Repository.get_data_stream_for_search`` which allows less network
+ traffic when requesting data streams over a smart server. (Robert Collins)
+
+* ``RemoteBzrDir._get_tree_branch`` no longer triggers ``_ensure_real``,
+ removing one round trip on many network operations. (Robert Collins)
+
+* RemoteTransport's ``recommended_page_size`` method now returns 64k, like
+ SFTPTransport and HttpTransportBase. (Andrew Bennetts)
+
+* Repository has a new method ``has_revisions`` which signals the presence
+ of many revisions by returning a set of the revisions listed which are
+ present. This can be done by index queries without reading data for parent
+ revision names etc. (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.3.txt b/doc/en/release-notes/bzr-1.3.txt
new file mode 100644
index 0000000..ba1ce31
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.3.txt
@@ -0,0 +1,239 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.3.1
+#########
+
+:Released: 2008-04-09
+
+No changes from 1.3.1rc1.
+
+
+bzr 1.3.1rc1
+############
+
+:Released: 2008-04-04
+
+Bug Fixes
+*********
+
+* Fix a bug causing a ValueError crash in ``parse_line_delta_iter`` when
+ fetching revisions from a knit to pack repository or vice versa using
+ bzr:// (including over HTTP or SSH).
+ (#208418, Andrew Bennetts, Martin Pool, Robert Collins)
+
+
+bzr 1.3
+#######
+
+:Released: 2008-03-20
+
+Bazaar has become part of the GNU project <http://www.gnu.org>
+
+Many operations that act on history, including ``log`` and ``annotate`` are now
+substantially faster. Several bugs have been fixed and several new options and
+features have been added.
+
+Testing
+*******
+
+* Avoid spurious failure of ``TestVersion.test_version`` matching
+ directory names.
+ (#202778, Martin Pool)
+
+
+bzr 1.3rc1
+##########
+
+:Released: 2008-03-16
+
+Notes When Upgrading
+********************
+
+* The backup directory created by ``upgrade`` is now called
+ ``backup.bzr``, not ``.bzr.backup``. (Martin Albisetti)
+
+Changes
+*******
+
+* A new repository format 'development' has been added. This format will
+ represent the latest 'in-progress' format that the bzr developers are
+ interested in getting early-adopter testing and feedback on.
+ ``doc/developers/development-repo.txt`` has detailed information.
+ (Robert Collins)
+
+* BZR_LOG environment variable controls location of .bzr.log trace file.
+ User can suppress writing messages to .bzr.log by using '/dev/null'
+ filename (on Unix) or 'NUL' (on Windows). If BZR_LOG variable
+ is not defined but BZR_HOME is defined then default location
+ for .bzr.log trace file is ``$BZR_HOME/.bzr.log``.
+ (Alexander Belchenko, #106117)
+
+* ``launchpad`` builtin plugin now shipped as separate part in standalone
+ bzr.exe, installed to ``C:\Program Files\Bazaar\plugins`` directory,
+ and standalone installer allows user to skip installation of this plugin.
+ (Alexander Belchenko)
+
+* Restore auto-detection of plink.exe on Windows. (Dmitry Vasiliev)
+
+* Version number is now shown as "1.2" or "1.2pr2", without zeroed or
+ missing final fields. (Martin Pool)
+
+Features
+********
+
+* ``branch`` and ``checkout`` can hard-link working tree files, which is
+ faster and saves space. (Aaron Bentley)
+
+* ``bzr send`` will now also look at the ``child_submit_to`` setting in
+ the submit branch to determine the email address to send to.
+ (Jelmer Vernooij)
+
+Improvements
+************
+
+* BzrBranch._lefthand_history is faster on pack repos. (Aaron Bentley)
+
+* Branch6.generate_revision_history is faster. (Aaron Bentley)
+
+* Directory services can now be registered, allowing special URLs to be
+ dereferenced into real URLs. This is a generalization and cleanup of
+ the lp: transport lookup. (Aaron Bentley)
+
+* Merge directives that are automatically attached to emails have nicer
+ filenames, based on branch-nick + revno. (Aaron Bentley)
+
+* ``push`` has a ``--revision`` option, to specify what revision to push up
+ to. (Daniel Watkins)
+
+* Significantly reducing execution time and network traffic for trivial
+ case of running ``bzr missing`` command for two identical branches.
+ (Alexander Belchenko)
+
+* Speed up operations that look at the revision graph (such as 'bzr log').
+ ``KnitPackRepositor.get_revision_graph`` uses ``Graph.iter_ancestry`` to
+ extract the revision history. This allows filtering ghosts while
+ stepping instead of needing to peek ahead. (John Arbash Meinel)
+
+* The ``hooks`` command lists installed hooks, to assist in debugging.
+ (Daniel Watkins)
+
+* Updates to how ``annotate`` work. Should see a measurable improvement in
+ performance and memory consumption for file with a lot of merges.
+ Also, correctly handle when a line is introduced by both parents (it
+ should be attributed to the first merge which notices this, and not
+ to all subsequent merges.) (John Arbash Meinel)
+
+Bugfixes
+********
+
+* Autopacking no longer holds the full set of inventory lines in
+ memory while copying. For large repositories, this can amount to
+ hundreds of MB of ram consumption.
+ (Ian Clatworthy, John Arbash Meinel)
+
+* Cherrypicking when using ``--format=merge3`` now explictly excludes
+ BASE lines. (John Arbash Meinel, #151731)
+
+* Disable plink's interactive prompt for password.
+ (#107593, Dmitry Vasiliev)
+
+* Encode command line arguments from unicode to user_encoding before
+ invoking external mail client in `bzr send` command.
+ (#139318, Alexander Belchenko)
+
+* Fixed problem connecting to ``bzr+https://`` servers.
+ (#198793, John Ferlito)
+
+* Improved error reporting in the Launchpad plugin. (Daniel Watkins,
+ #196618)
+
+* Include quick-start-summary.svg file to python-based installer(s)
+ for Windows. (#192924, Alexander Belchenko)
+
+* lca merge now respects specified files. (Aaron Bentley)
+
+* Make version-info --custom imply --all. (#195560, James Westby)
+
+* ``merge --preview`` now works for merges that add or modify
+ symlinks (James Henstridge)
+
+* Redirecting the output from ``bzr merge`` (when the remembered
+ location is used) now works. (John Arbash Meinel)
+
+* setup.py script explicitly checks for Python version.
+ (Jari Aalto, Alexander Belchenko, #200569)
+
+* UnknownFormatErrors no longer refer to branches regardless of kind of
+ unknown format. (Daniel Watkins, #173980)
+
+* Upgrade bundled ConfigObj to version 4.5.2, which properly quotes #
+ signs, among other small improvements. (Matt Nordhoff, #86838)
+
+* Use correct indices when emitting LCA conflicts. This fixes IndexError
+ errors. (Aaron Bentley, #196780)
+
+Documentation
+*************
+
+* Explained how to use ``version-info --custom`` in the User Guide.
+ (Neil Martinsen-Burrell)
+
+API Breaks
+**********
+
+* Support for loading plugins from zip files and
+ ``bzrlib.plugin.load_from_zip()`` function are deprecated.
+ (Alexander Belchenko)
+
+Testing
+*******
+
+* Added missing blackbox tests for ``modified`` (Adrian Wilkins)
+
+* The branch interface tests were invalid for branches using rich-root
+ repositories because the empty string is not a valid file-id.
+ (Robert Collins)
+
+Internals
+*********
+
+* ``Graph.iter_ancestry`` returns the ancestry of revision ids. Similar to
+ ``Repository.get_revision_graph()`` except it includes ghosts and you can
+ stop part-way through. (John Arbash Meinel)
+
+* New module ``tools/package_mf.py`` provide custom module finder for
+ python packages (improves standard python library's modulefinder.py)
+ used by ``setup.py`` script while building standalone bzr.exe.
+ (Alexander Belchenko)
+
+* New remote method ``RemoteBzrDir.find_repositoryV2`` adding support for
+ detecting external lookup support on remote repositories. This method is
+ now attempted first when lookup up repositories, leading to an extra
+ round trip on older bzr smart servers. (Robert Collins)
+
+* Repository formats have a new supported-feature attribute
+ ``supports_external_lookups`` used to indicate repositories which support
+ falling back to other repositories when they have partial data.
+ (Robert Collins)
+
+* ``Repository.get_revision_graph_with_ghosts`` and
+ ``bzrlib.revision.(common_ancestor,MultipleRevisionSources,common_graph)``
+ have been deprecated. (John Arbash Meinel)
+
+* ``Tree.iter_changes`` is now a public API, replacing the work-in-progress
+ ``Tree._iter_changes``. The api is now considered stable and ready for
+ external users. (Aaron Bentley)
+
+* The bzrdir format registry now accepts an ``alias`` keyword to
+ register_metadir, used to indicate that a format name is an alias for
+ some other format and thus should not be reported when describing the
+ format. (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.4.txt b/doc/en/release-notes/bzr-1.4.txt
new file mode 100644
index 0000000..8501756
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.4.txt
@@ -0,0 +1,347 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.4
+#######
+
+:Released: 2008-04-28
+
+This release of Bazaar includes handy improvements to the speed of log and
+status, new options for several commands, improved documentation, and better
+hooks, including initial code for server-side hooks. A number of bugs have
+been fixed, particularly in interoperability between different formats or
+different releases of Bazaar over there network. There's been substantial
+internal work in both the repository and network code to enable new features
+and faster performance.
+
+Bug Fixes
+*********
+
+* Pushing a branch in "dirstate" format (Branch5) over bzr+ssh would break
+ if the remote server was < version 1.2. This was due to a bug in the
+ RemoteRepository.get_parent_map() fallback code.
+ (John Arbash Meinel, Andrew Bennetts, #214894)
+
+
+bzr 1.4rc2
+##########
+
+:Released: 2008-04-21
+
+Bug Fixes
+*********
+
+* ``bzr log -r ..X bzr://`` was failing, because it was getting a request
+ for ``revision_id=None`` which was not a string.
+ (John Arbash Meinel, #211661)
+
+* Fixed a bug in handling ghost revisions when logging changes in a
+ particular file. (John Arbash Meinel, #209948)
+
+* Fix error about "attempt to add line-delta in non-delta knit".
+ (Andrew Bennetts, #205156)
+
+* Fixed performance degradation in fetching from knit repositories to
+ knits and packs due to parsing the entire revisions.kndx on every graph
+ walk iteration fixed by using the Repository.get_graph API. There was
+ another regression in knit => knit fetching which re-read the index for
+ every revision each side had in common.
+ (Robert Collins, John Arbash Meinel)
+
+
+bzr 1.4rc1
+##########
+
+:Released: 2008-04-11
+
+Changes
+*******
+
+* bzr main script cannot be imported (Benjamin Peterson)
+
+* On GNU/Linux bzr additionally looks for plugins in arch-independent site
+ directory. (Toshio Kuratomi)
+
+* The ``set_rh`` branch hook is now deprecated. Please migrate
+ any plugins using this hook to use an alternative, e.g.
+ ``post_change_branch_tip``. (Ian Clatworthy)
+
+* When a plugin cannot be loaded as the file path is not a valid
+ python module name bzr will now strip a ``bzr_`` prefix from the
+ front of the suggested name, as many plugins (e.g. bzr-svn)
+ want to be installed without this prefix. It is a common mistake
+ to have a folder named "bzr-svn" for that plugin, especially
+ as this is what bzr branch lp:bzr-svn will give you. (James Westby,
+ Andrew Cowie)
+
+* UniqueIntegerBugTracker now appends bug-ids instead of joining
+ them to the base URL. Plugins that register bug trackers may
+ need a trailing / added to the base URL if one is not already there.
+ (James Wesby, Andrew Cowie)
+
+Features
+********
+
+* Added start_commit hook for mutable trees. (Jelmer Vernooij, #186422)
+
+* ``status`` now accepts ``--no-pending`` to show the status without
+ listing pending merges, which speeds up the command a lot on large
+ histories. (James Westby, #202830)
+
+* New ``post_change_branch_tip`` hook that is called after the
+ branch tip is moved but while the branch is still write-locked.
+ See the User Reference for signature details.
+ (Ian Clatworthy, James Henstridge)
+
+* Reconfigure can convert a branch to be standalone or to use a shared
+ repository. (Aaron Bentley)
+
+Improvements
+************
+
+* The smart protocol now has support for setting branches' revision info
+ directly. This should make operations like push slightly faster, and is a
+ step towards server-side hooks. The new request method name is
+ ``Branch.set_last_revision_info``. (Andrew Bennetts)
+
+* ``bzr commit --fixes`` now recognises "gnome" as a tag by default.
+ (James Westby, Andrew Cowie)
+
+* ``bzr switch`` will attempt to find branches to switch to relative to the
+ current branch. E.g. ``bzr switch branchname`` will look for
+ ``current_branch/../branchname``. (Robert Collins, Jelmer Vernooij,
+ Wouter van Heyst)
+
+* Diff is now more specific about execute-bit changes it describes
+ (Chad Miller)
+
+* Fetching data over HTTP is a bit faster when urllib is used. This is done
+ by forcing it to recv 64k at a time when reading lines in HTTP headers,
+ rather than just 1 byte at a time. (Andrew Bennetts)
+
+* Log --short and --line are much faster when -r is not specified.
+ (Aaron Bentley)
+
+* Merge is faster. We no longer check a file's existence unnecessarily
+ when merging the execute bit. (Aaron Bentley)
+
+* ``bzr status`` on an explicit list of files no longer shows pending
+ merges, making it much faster on large trees. (John Arbash Meinel)
+
+* The launchpad directory service now warns the user if they have not set
+ their launchpad login and are trying to resolve a URL using it, just
+ in case they want to do a write operation with it. (James Westby)
+
+* The smart protocol client is slightly faster, because it now only queries
+ the server for the protocol version once per connection. Also, the HTTP
+ transport will now automatically probe for and use a smart server if
+ one is present. You can use the new ``nosmart+`` transport decorator
+ to get the old behaviour. (Andrew Bennetts)
+
+* The ``version`` command takes a ``--short`` option to print just the
+ version number, for easier use in scripts. (Martin Pool)
+
+* Various operations with revision specs and commands that calculate
+ revnos and revision ids are faster. (John A. Meinel, Aaron Bentley)
+
+Bugfixes
+********
+
+* Add ``root_client_path`` parameter to SmartWSGIApp and
+ SmartServerRequest. This makes it possible to publish filesystem
+ locations that don't exactly match URL paths. SmartServerRequest
+ subclasses should use the new ``translate_client_path`` and
+ ``transport_from_client_path`` methods when dealing with paths received
+ from a client to take this into account. (Andrew Bennetts, #124089)
+
+* ``bzr mv a b`` can be now used also to rename previously renamed
+ directories, not only files. (Lukáš Lalinský, #107967)
+
+* ``bzr uncommit --local`` can now remove revisions from the local
+ branch to be symmetric with ``bzr commit --local``.
+ (John Arbash Meinel, #93412)
+
+* Don't ask for a password if there is no real terminal.
+ (Alexander Belchenko, #69851)
+
+* Fix a bug causing a ValueError crash in ``parse_line_delta_iter`` when
+ fetching revisions from a knit to pack repository or vice versa using
+ bzr:// (including over HTTP or SSH).
+ (#208418, Andrew Bennetts, Martin Pool, Robert Collins)
+
+* Fixed ``_get_line`` in ``bzrlib.smart.medium``, which was buggy. Also
+ fixed ``_get_bytes`` in the same module to use the push back buffer.
+ These bugs had no known impact in normal use, but were problematic for
+ developers working on the code, and were likely to cause real bugs sooner
+ or later. (Andrew Bennetts)
+
+* Implement handling of basename parameter for DefaultMail. (James Westby)
+
+* Incompatibility with Paramiko versions newer than 1.7.2 was fixed.
+ (Andrew Bennetts, #213425)
+
+* Launchpad locations (lp: URLs) can be pulled. (Aaron Bentley, #181945)
+
+* Merges that add files to deleted root directories complete. They
+ do create conflicts. (Aaron Bentley, #210092)
+
+* vsftp's return ``550 RNFR command failed.`` supported.
+ (Marcus Trautwig, #129786)
+
+Documentation
+*************
+
+* Improved documentation on send/merge relationship. (Peter Schuller)
+
+* Minor fixes to the User Guide. (Matthew Fuller)
+
+* Reduced the evangelism in the User Guide. (Ian Clatworthy)
+
+* Added Integrating with Bazaar document for developers (Martin Albisetti)
+
+API Breaks
+**********
+
+* Attempting to pull data from a ghost aware repository (e.g. knits) into a
+ non-ghost aware repository such as weaves will now fail if there are
+ ghosts. (Robert Collins)
+
+* ``KnitVersionedFile`` no longer accepts an ``access_mode`` parameter, and
+ now requires the ``index`` and ``access_method`` parameters to be
+ supplied. A compatible shim has been kept in the new function
+ ``knit.make_file_knit``. (Robert Collins)
+
+* Log formatters must now provide log_revision instead of show and
+ show_merge_revno methods. The latter had been deprecated since the 0.17
+ release. (James Westby)
+
+* ``LoopbackSFTP`` is now called ``SocketAsChannelAdapter``.
+ (Andrew Bennetts)
+
+* ``osutils.backup_file`` is removed. (Alexander Belchenko)
+
+* ``Repository.get_revision_graph`` is deprecated, with no replacement
+ method. The method was size(history) and not desirable. (Robert Collins)
+
+* ``revision.revision_graph`` is deprecated, with no replacement function.
+ The function was size(history) and not desirable. (Robert Collins)
+
+* ``Transport.get_shared_medium`` is deprecated. Use
+ ``Transport.get_smart_medium`` instead. (Andrew Bennetts)
+
+* ``VersionedFile`` factories now accept a get_scope parameter rather
+ than using a call to ``transaction_finished``, allowing the removal of
+ the fixed list of versioned files per repository. (Robert Collins)
+
+* ``VersionedFile.annotate_iter`` is deprecated. While in principle this
+ allowed lower memory use, all users of annotations wanted full file
+ annotations, and there is no storage format suitable for incremental
+ line-by-line annotation. (Robert Collins)
+
+* ``VersionedFile.clone_text`` is deprecated. This performance optimisation
+ is no longer used - reading the content of a file that is undergoing a
+ file level merge to identical state on two branches is rare enough, and
+ not expensive enough to special case. (Robert Collins)
+
+* ``VersionedFile.clear_cache`` and ``enable_cache`` are deprecated.
+ These methods added significant complexity to the ``VersionedFile``
+ implementation, but were only used for optimising fetches from knits -
+ which can be done from outside the knit layer, or via a caching
+ decorator. As knits are not the default format, the complexity is no
+ longer worth paying. (Robert Collins)
+
+* ``VersionedFile.create_empty`` is removed. This method presupposed a
+ sensible mapping to a transport for individual files, but pack backed
+ versioned files have no such mapping. (Robert Collins)
+
+* ``VersionedFile.get_graph`` is deprecated, with no replacement method.
+ The method was size(history) and not desirable. (Robert Collins)
+
+* ``VersionedFile.get_graph_with_ghosts`` is deprecated, with no
+ replacement method. The method was size(history) and not desirable.
+ (Robert Collins)
+
+* ``VersionedFile.get_parents`` is deprecated, please use
+ ``VersionedFile.get_parent_map``. (Robert Collins)
+
+* ``VersionedFile.get_sha1`` is deprecated, please use
+ ``VersionedFile.get_sha1s``. (Robert Collins)
+
+* ``VersionedFile.has_ghost`` is now deprecated, as it is both expensive
+ and unused outside of a single test. (Robert Collins)
+
+* ``VersionedFile.iter_parents`` is now deprecated in favour of
+ ``get_parent_map`` which can be used to instantiate a Graph on a
+ VersionedFile. (Robert Collins)
+
+* ``VersionedFileStore`` no longer uses the transaction parameter given
+ to most methods; amongst other things this means that the
+ get_weave_or_empty method no longer guarantees errors on a missing weave
+ in a readonly transaction, and no longer caches versioned file instances
+ which reduces memory pressure (but requires more careful management by
+ callers to preserve performance). (Robert Collins)
+
+Testing
+*******
+
+* New -Dselftest_debug flag disables clearing of the debug flags during
+ tests. This is useful if you want to use e.g. -Dhpss to help debug a
+ failing test. Be aware that using this feature is likely to cause
+ spurious test failures if used with the full suite. (Andrew Bennetts)
+
+* selftest --load-list now uses a new more agressive test loader that will
+ avoid loading unneeded modules and building their tests. Plugins can use
+ this new loader by defining a load_tests function instead of a test_suite
+ function. (a forthcoming patch will provide many examples on how to
+ implement this).
+ (Vincent Ladeuil)
+
+* selftest --load-list now does some sanity checks regarding duplicate test
+ IDs and tests present in the list but not found in the actual test suite.
+ (Vincent Ladeuil)
+
+* Slightly more concise format for the selftest progress bar, so there's
+ more space to show the test name. (Martin Pool) ::
+
+ [2500/10884, 1fail, 3miss in 1m29s] test_revisionnamespaces.TestRev
+
+* The test suite takes much less memory to run, and is a bit faster. This
+ is done by clearing most attributes of TestCases after running them, if
+ they succeeded. (Andrew Bennetts)
+
+Internals
+*********
+
+* Added ``_build_client_protocol`` to ``_SmartClient``. (Andrew Bennetts)
+
+* Added basic infrastructure for automatic plugin suggestion.
+ (Martin Albisetti)
+
+* If a ``LockableFiles`` object is not explicitly unlocked (for example
+ because of a missing ``try/finally`` block, it will give a warning but
+ not automatically unlock itself. (Previously they did.) This
+ sometimes caused knock-on errors if for example the network connection
+ had already failed, and should not be relied upon by code.
+ (Martin Pool, #109520)
+
+* ``make dist`` target to build a release tarball, and also
+ ``check-dist-tarball`` and ``dist-upload-escudero``. (Martin Pool)
+
+* The ``read_response_tuple`` method of ``SmartClientRequestProtocol*``
+ classes will now raise ``UnknownSmartMethod`` when appropriate, so that
+ callers don't need to try distinguish unknown request errors from other
+ errors. (Andrew Bennetts)
+
+* ``set_make_working_trees`` is now implemented provided on all repository
+ implementations (Aaron Bentley)
+
+* ``VersionedFile`` now has a new method ``get_parent_map`` which, like
+ ``Graph.get_parent_map`` returns a dict of key:parents. (Robert Collins)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.5.txt b/doc/en/release-notes/bzr-1.5.txt
new file mode 100644
index 0000000..370fd76
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.5.txt
@@ -0,0 +1,206 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.5
+#######
+
+:Released: 2008-05-16
+
+This release of Bazaar includes several updates to the documentation, and fixes
+to prepare for making rich root support the default format. Many bugs have been
+squashed, including fixes to log, bzr+ssh inter-operation with older servers.
+
+Changes
+*******
+
+* Suppress deprecation warnings when bzrlib is a 'final' release. This way
+ users of packaged software won't be bothered with DeprecationWarnings,
+ but developers and testers will still see them. (John Arbash Meinel)
+
+Documentation
+*************
+
+* Incorporate feedback from Jelmer Vernooij and Neil Martinsen-Burrell
+ on the plugin and integration chapters of the User Guide.
+ (Ian Clatworthy)
+
+
+bzr 1.5rc1
+##########
+
+:Released: 2008-05-09
+
+Changes
+*******
+
+* Broader support of GNU Emacs mail clients. Set
+ ``mail_client=emacsclient`` in your bazaar.conf and ``send`` will pop the
+ bundle in a mail buffer according to the value of ``mail-user-agent``
+ variable. (Xavier Maillard)
+
+Improvements
+************
+
+* Diff now handles revision specs like "branch:" and "submit:" more
+ efficiently. (Aaron Bentley, #202928)
+
+* More friendly error given when attempt to start the smart server
+ on an address already in use. (Andrea Corbellini, #200575)
+
+* Pull completes much faster when there is nothing to pull.
+ (Aaron Bentley)
+
+Bugfixes
+********
+
+* Authentication.conf can define sections without password.
+ (Vincent Ladeuil, #199440)
+
+* Avoid muttering every time a child update does not cause a progress bar
+ update. (John Arbash Meinel, #213771)
+
+* ``Branch.reconcile()`` is now implemented. This allows ``bzr reconcile``
+ to fix when a Branch has a non-canonical mainline history. ``bzr check``
+ also detects this condition. (John Arbash Meinel, #177855)
+
+* ``bzr log -r ..X bzr://`` was failing, because it was getting a request
+ for ``revision_id=None`` which was not a string.
+ (John Arbash Meinel, #211661)
+
+* ``bzr commit`` now works with Microsoft's FTP service.
+ (Andreas Deininger)
+
+* Catch definitions outside sections in authentication.conf.
+ (Vincent Ladeuil, #217650)
+
+* Conversion from non-rich-root to rich-root(-pack) updates inventory
+ sha1s, even when bundles are used. (Aaron Bentley, #181391)
+
+* Conversion from non-rich-root to rich-root(-pack) works correctly even
+ though search keys are not topologically sorted. (Aaron Bentley)
+
+* Conversion from non-rich-root to rich-root(-pack) works even when a
+ parent revision has a different root id. (Aaron Bentley, #177874)
+
+* Disable strace testing until strace is fixed (see bug #103133) and emit a
+ warning when selftest ends to remind us of leaking tests.
+ (Vincent Ladeuil, #226769)
+
+* Fetching all revisions from a repository does not cause pack collisions.
+ (Robert Collins, Aaron Bentley, #212908)
+
+* Fix error about "attempt to add line-delta in non-delta knit".
+ (Andrew Bennetts, #217701)
+
+* Pushing a branch in "dirstate" format (Branch5) over bzr+ssh would break
+ if the remote server was < version 1.2. This was due to a bug in the
+ RemoteRepository.get_parent_map() fallback code.
+ (John Arbash Meinel, #214894)
+
+* Remove leftover code in ``bzr_branch`` that inappropriately creates
+ a ``branch-name`` file in the branch control directory.
+ (Martin Pool)
+
+* Set SO_REUSEADDR on server sockets of ``bzr serve`` to avoid problems
+ rebinding the socket when starting the server a second time.
+ (John Arbash Meinel, Martin Pool, #164288)
+
+* Severe performance degradation in fetching from knit repositories to
+ knits and packs due to parsing the entire revisions.kndx on every graph
+ walk iteration fixed by using the Repository.get_graph API. There was
+ another regression in knit => knit fetching which re-read the index for
+ every revision each side had in common.
+ (Robert Collins, John Arbash Meinel)
+
+* When logging the changes to a particular file, there was a bug if there
+ were ghosts in the revision ancestry. (John Arbash Meinel, #209948)
+
+* xs4all's FTP server returns a temporary error when trying to list an
+ empty directory, rather than returning an empty list. Adding a
+ workaround so that we don't get spurious failures.
+ (John Arbash Meinel, #215522)
+
+Documentation
+*************
+
+* Expanded the User Guide to include new chapters on popular plugins and
+ integrating Bazaar into your environment. The *Best practices* chapter
+ was renamed to *Miscellaneous topics* as suggested by community
+ feedback as well. (Ian Clatworthy)
+
+* Document outlining strategies for TortoiseBzr. (Mark Hammond)
+
+* Improved the documentation on hooks. (Ian Clatworthy)
+
+* Update authentication docs regarding SSH agents.
+ (Vincent Ladeuil, #183705)
+
+Testing
+*******
+
+* Add ``thread_name_suffix`` parameter to SmartTCPServer_for_testing, to
+ make it easy to identify which test spawned a thread with an unhandled
+ exception. (Andrew Bennetts)
+
+* New ``--debugflag``/``-E`` option to ``bzr selftest`` for setting
+ options for debugging tests, these are complementary to the -D
+ options. The ``-Dselftest_debug`` global option has been replaced by the
+ ``-E=allow_debug`` option for selftest. (Andrew Bennetts)
+
+* Parameterised test ids are preserved correctly to aid diagnosis of test
+ failures. (Robert Collins, Andrew Bennetts)
+
+* selftest now accepts --starting-with <id> to load only the tests whose id
+ starts with the one specified. This greatly speeds up running the test
+ suite on a limited set of tests and can be used to run the tests for a
+ single module, a single class or even a single test. (Vincent Ladeuil)
+
+* The test suite modules have been modified to define load_tests() instead
+ of test_suite(). That speeds up selective loading (via --load-list)
+ significantly and provides many examples on how to migrate (grep for
+ load_tests). (Vincent Ladeuil)
+
+Internals
+*********
+
+* ``Hooks.install_hook`` is now deprecated in favour of
+ ``Hooks.install_named_hook`` which adds a required ``name`` parameter, to
+ avoid having to call ``Hooks.name_hook``. (Daniel Watkins)
+
+* Implement xml8 serializer. (Aaron Bentley)
+
+* New form ``@deprecated_method(deprecated_in(1, 5, 0))`` for making
+ deprecation wrappers. (Martin Pool)
+
+* ``Repository.revision_parents`` is now deprecated in favour of
+ ``Repository.get_parent_map([revid])[revid]``. (Jelmer Vernooij)
+
+* The Python ``assert`` statement is no longer used in Bazaar source, and
+ a test checks this. (Martin Pool)
+
+API Changes
+***********
+
+* ``bzrlib.status.show_pending_merges`` requires the repository to be
+ locked by the caller. Callers should have been doing it anyway, but it
+ will now raise an exception if they do not. (John Arbash Meinel)
+
+* Repository.get_data_stream, Repository.get_data_stream_for_search(),
+ Repository.get_deltas_for_revsions(), Repository.revision_trees(),
+ Repository.item_keys_introduced_by() no longer take read locks.
+ (Aaron Bentley)
+
+* ``LockableFiles.get_utf8`` and ``.get`` are deprecated, as a start
+ towards removing LockableFiles and ``.control_files`` entirely.
+ (Martin Pool)
+
+* Methods deprecated prior to 1.1 have been removed.
+ (Martin Pool)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.6.txt b/doc/en/release-notes/bzr-1.6.txt
new file mode 100644
index 0000000..19fbd8e
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.6.txt
@@ -0,0 +1,818 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.6.1
+#########
+
+:Released: 2008-09-05
+
+A couple regressions were found in the 1.6 release. There was a
+performance issue when using ``bzr+ssh`` to branch large repositories,
+and some problems with stacking and ``rich-root`` capable repositories.
+
+
+bzr 1.6.1rc2
+############
+
+:Released: 2008-09-03
+
+Bug Fixes
+*********
+
+* Copying between ``rich-root`` and ``rich-root-pack`` (and vice
+ versa) was accidentally using the inter-model fetcher, instead of
+ recognizing that both were 'rich root' formats.
+ (John Arbash Meinel, #264321)
+
+
+bzr 1.6.1rc1
+############
+
+:Released: 2008-08-29
+
+This release fixes a few regressions found in the 1.6 client. Fetching
+changes was using an O(N^2) buffering algorithm, so for large projects it
+would cause memory thrashing. There is also a specific problem with the
+``--1.6-rich-root`` format, which prevented stacking on top of
+``--rich-root-pack`` repositories, and could allow users to accidentally
+fetch experimental data (``-subtree``) without representing it properly.
+The ``--1.6-rich-root`` format has been deprecated and users are
+recommended to upgrade to ``--1.6.1-rich-root`` immediately. Also we
+re-introduced a workaround for users who have repositories with incorrect
+nodes (not possible if you only used official releases).
+I should also clarify that none of this is data loss level issues, but
+still sufficient enough to warrant an updated release.
+
+Bug Fixes
+*********
+
+* ``RemoteTransport.readv()`` was being inefficient about how it
+ buffered the readv data and processed it. It would keep appending to
+ the same string (causing many copies) and then pop bytes out of the
+ start of the string (causing more copies).
+ With this patch "bzr+ssh://local" can improve dramatically,
+ especially for projects with large files.
+ (John Arbash Meinel)
+
+* Revision texts were always meant to be stored as fulltexts. There
+ was a bug in a bzr.dev version that would accidentally create deltas
+ when copying from a Pack repo to a Knit repo. This has been fixed,
+ but to support those repositories, we know always request full texts
+ for Revision texts. (John Arbash Meinel, #261339)
+
+* The previous ``--1.6-rich-root`` format used an incorrect XML
+ serializer, which would accidentally support fetching from a
+ repository that supported subtrees, even though the local one would
+ not. We deprecated that format, and introduced a new one that uses
+ the correct serializer ``--1.6.1-rich-root``.
+ (John Arbash Meinel, #262333)
+
+
+bzr 1.6
+#######
+
+:Released: 2008-08-25
+
+Finally, the long awaited bzr 1.6 has been released. This release includes
+new features like Stacked Branches, improved weave merge, and an updated
+server protocol (now on v3) which will allow for better cross version
+compatibility. With this release we have deprecated Knit format
+repositories, and recommend that users upgrade them, we will continue to
+support reading and writing them for the forseeable future, but we will
+not be tuning them for performance as pack repositories have proven to be
+better at scaling. This will also be the first release to bundle
+TortoiseBzr in the standalone Windows installer.
+
+
+bzr 1.6rc5
+##########
+
+:Released: 2008-08-19
+
+Bug Fixes
+*********
+
+* Disable automatic detection of stacking based on a containing
+ directory of the target. It interacted badly with push, and needs a
+ bit more work to get the edges polished before it should happen
+ automatically. (John Arbash Meinel, #259275)
+ (This change was reverted when merged to bzr.dev)
+
+
+bzr 1.6rc4
+##########
+
+:Released: 2008-08-18
+
+Bug Fixes
+*********
+
+* Fix a regression in knit => pack fetching. We had a logic
+ inversion, causing the fetch to insert fulltexts in random order,
+ rather than preserving deltas. (John Arbash Meinel, #256757)
+
+
+bzr 1.6rc3
+##########
+
+:Released: 2008-08-14
+
+Changes
+*******
+
+* Disable reading ``.bzrrules`` as a per-branch rule preferences
+ file. The feature was not quite ready for a full release.
+ (Robert Collins)
+
+Improvements
+************
+
+* Update the windows installer to bundle TortoiseBzr and ``qbzr``
+ into the standalone installer. This will be the first official
+ windows release that installs Tortoise by default.
+ (Mark Hammond)
+
+Bug Fixes
+*********
+
+* Fix a regression in ``bzr+http`` support. There was a missing
+ function (``_read_line``) that needed to be carried over from
+ ``bzr+ssh`` support. (Andrew Bennetts)
+
+* ``GraphIndex`` objects will internally read an entire index if more
+ than 1/20th of their keyspace is requested in a single operation.
+ This largely mitigates a performance regression in ``bzr log FILE``
+ and completely corrects the performance regression in ``bzr log``.
+ The regression was caused by removing an accomodation which had been
+ supporting the index format in use. A newer index format is in
+ development which is substantially faster. (Robert Collins)
+
+
+bzr 1.6rc2
+##########
+
+:Released: 2008-08-13
+
+This release candidate has a few minor bug fixes, and some regression
+fixes for Windows.
+
+Bug Fixes
+*********
+
+* ``bzr upgrade`` on remote branches accessed via bzr:// and
+ bzr+ssh:// now works. (Andrew Bennetts)
+
+* Change the ``get_format_description()`` strings for
+ ``RepositoryFormatKnitPack5`` et al to be single line messages.
+ (Aaron Bentley)
+
+* Fix for a regression on Win32 where we would try to call
+ ``os.listdir()`` on a file and not catch the exception properly.
+ (Windows raises a different exception.) This would manifest in
+ places like ``bzr rm file`` or ``bzr switch``.
+ (Mark Hammond, John Arbash Meinel)
+
+* ``Inventory.copy()`` was failing to set the revision property for
+ the root entry. (Jelmer Vernooij)
+
+* SFTP transport: added missing ``FileExists`` case to
+ ``_translate_io_exception`` (Christophe Troestler, #123475)
+
+* The help for ``bzr ignored`` now suggests ``bzr ls --ignored`` for
+ scripting use. (Robert Collins, #3834)
+
+* The default ``annotate`` logic will now always assign the
+ last-modified value of a line to one of the revisions that modified
+ it, rather than a merge revision. This would happen when both sides
+ claimed to have modified the line resulting in the same text. The
+ choice is arbitrary but stable, so merges in different directions
+ will get the same results. (John Arbash Meinel, #232188)
+
+
+bzr 1.6rc1
+##########
+
+:Released: 2008-08-06
+
+This release candidate for bzr 1.6 solidifies the new branch stacking
+feature. Bazaar now recommends that users upgrade all knit repositories,
+because later formats are much faster. However, we plan to continue read/write and
+upgrade support for knit repostories for the forseeable future. Several
+other bugs and performance issues were fixed.
+
+Changes
+*******
+
+* Knit format repositories are deprecated and bzr will now emit
+ warnings whenever it encounters one. Use ``bzr upgrade`` to upgrade
+ knit repositories to pack format. (Andrew Bennetts)
+
+Improvements
+************
+
+* ``bzr check`` can now be told which elements at a location it should
+ check. (Daniel Watkins)
+
+* Commit now supports ``--exclude`` (or ``-x``) to exclude some files
+ from the commit. (Robert Collins, #3117)
+
+* Fetching data between repositories that have the same model but no
+ optimised fetcher will not reserialise all the revisions, increasing
+ performance. (Robert Collins, John Arbash Meinel)
+
+* Give a more specific error when target branch is not reachable.
+ (James Westby)
+
+* Implemented a custom ``walkdirs_utf8`` implementation for win32.
+ This uses a pyrex extension to get direct access to the
+ ``FindFirstFileW`` style apis, rather than using ``listdir`` +
+ ``lstat``. Shows a very strong improvement in commands like
+ ``status`` and ``diff`` which have to iterate the working tree.
+ Anywhere from 2x-6x faster depending on the size of the tree (bigger
+ trees, bigger benefit.) (John Arbash Meinel)
+
+* New registry for log properties handles and the method in
+ LongLogFormatter to display the custom properties returned by the
+ registered handlers. (Guillermo Gonzalez, #162469)
+
+Bug Fixes
+*********
+
+* Add more tests that stacking does not create deltas spanning
+ physical repository boundaries.
+ (Martin Pool, #252428)
+
+* Better message about incompatible repositories.
+ (Martin Pool, #206258)
+
+* ``bzr branch --stacked`` ensures the destination branch format can
+ support stacking, even if the origin does not.
+ (Martin Pool)
+
+* ``bzr export`` no longer exports ``.bzrrules``.
+ (Ian Clatworthy)
+
+* ``bzr serve --directory=/`` now correctly allows the whole
+ filesystem to be accessed on Windows, not just the root of the drive
+ that Python is running from.
+ (Adrian Wilkins, #240910)
+
+* Deleting directories by hand before running ``bzr rm`` will not
+ cause subsequent errors in ``bzr st`` and ``bzr commit``.
+ (Robert Collins, #150438)
+
+* Fix a test case that was failing if encoding wasn't UTF-8.
+ (John Arbash Meinel, #247585)
+
+* Fix "no buffer space available" error when branching with the new
+ smart server protocol to or from Windows.
+ (Andrew Bennetts, #246180)
+
+* Fixed problem in branching from smart server.
+ (#249256, Michael Hudson, Martin Pool)
+
+* Handle a file turning in to a directory in TreeTransform.
+ (James Westby, #248448)
+
+API Changes
+***********
+
+* ``MutableTree.commit`` has an extra optional keywork parameter
+ ``exclude`` that will be unconditionally supplied by the command
+ line UI - plugins that add tree formats may need an update.
+ (Robert Collins)
+
+* The API minimum version for plugin compatibility has been raised to
+ 1.6 - there are significant changes throughout the code base.
+ (Robert Collins)
+
+* The generic fetch code now uses three attributes on Repository objects
+ to control fetch. The streams requested are controlled via :
+ ``_fetch_order`` and ``_fetch_uses_deltas``. Setting these
+ appropriately allows different repository implementations to recieve
+ data in their optimial form. If the ``_fetch_reconcile`` is set then
+ a reconcile operation is triggered at the end of the fetch.
+ (Robert Collins)
+
+* The ``put_on_disk`` and ``get_tar_item`` methods in
+ ``InventoryEntry`` were deprecated. (Ian Clatworthy)
+
+* ``Repository.is_shared`` doesn't take a read lock. It didn't
+ need one in the first place (nobody cached the value, and
+ ``RemoteRepository`` wasn't taking one either). This saves a round
+ trip when probing Pack repositories, as they read the ``pack-names``
+ file when locked. And during probe, locking the repo isn't very
+ useful. (John Arbash Meinel)
+
+Internals
+*********
+
+* ``bzrlib.branchbuilder.BranchBuilder`` is now much more capable of
+ putting together a real history without having to create a full
+ WorkingTree. It is recommended that tests that are not directly
+ testing the WorkingTree use BranchBuilder instead. See
+ ``BranchBuilder.build_snapshot`` or
+ ``TestCaseWithMemoryTree.make_branch_builder``. (John Arbash Meinel)
+
+* ``bzrlib.builtins.internal_tree_files`` broken into two giving a new
+ helper ``safe_relpath_files`` - used by the new ``exclude``
+ parameter to commit. (Robert Collins)
+
+* Make it easier to introduce new WorkingTree formats.
+ (Ian Clatworthy)
+
+* The code for exporting trees was refactored not to use the
+ deprecated ``InventoryEntry`` methods. (Ian Clatworthy)
+
+* RuleSearchers return () instead of [] now when there are no matches.
+ (Ian Clatworthy)
+
+
+bzr 1.6beta3
+############
+
+:Released: 2008-07-17
+
+This release adds a new 'stacked branches' feature allowing branches to
+share storage without being in the same repository or on the same machine.
+(See the user guide for more details.) It also adds a new hook, improved
+weaves, aliases for related locations, faster bzr+ssh push, and several
+bug fixes.
+
+Features
+********
+
+* New ``pre_change_branch_tip`` hook that is called before the
+ branch tip is moved, while the branch is write-locked. See the User
+ Reference for signature details. (Andrew Bennetts)
+
+* Rule-based preferences can now be defined for selected files in
+ selected branches, allowing commands and plugins to provide
+ custom behaviour for files matching defined patterns.
+ See ``Rule-based preferences`` (part of ``Configuring Bazaar``)
+ in the User Guide and ``bzr help rules`` for more information.
+ (Ian Clatworthy)
+
+* Sites may suggest a branch to stack new branches on. (Aaron Bentley)
+
+* Stacked branches are now supported. See ``bzr help branch`` and
+ ``bzr help push``. Branches must be in the ``development1`` format
+ to stack, though the stacked-on branch can be of any format.
+ (Robert Collins)
+
+Improvements
+************
+
+* ``bzr export --format=tgz --root=NAME -`` to export a gzipped tarball
+ to stdout; also ``tar`` and ``tbz2``.
+ (Martin Pool)
+
+* ``bzr (re)merge --weave`` will now use a standard Weave algorithm,
+ rather than the annotation-based merge it was using. It does so by
+ building up a Weave of the important texts, without needing to build
+ the full ancestry. (John Arbash Meinel, #238895)
+
+* ``bzr send`` documents and better supports ``emacsclient`` (proper
+ escaping of mail headers and handling of the MUA Mew).
+ (Christophe Troestler)
+
+* Remembered locations can be specified by aliases, e.g. :parent, :public,
+ :submit. (Aaron Bentley)
+
+* The smart protocol now has improved support for setting branches'
+ revision info directly. This makes operations like push
+ faster. The new request method name is
+ ``Branch.set_last_revision_ex``. (Andrew Bennetts)
+
+Bug Fixes
+*********
+
+* Bazaar is now able to be a client to the web server of IIS 6 and 7.
+ The broken implementations of RFC822 in Python and RFC2046 in IIS
+ combined with boundary-line checking in Bazaar previously made this
+ impossible. (NB, IIS 5 does not suffer from this problem).
+ (Adrian Wilkins, #247585)
+
+* ``bzr log --long`` with a ghost in your mainline now handles that
+ ghost properly. (John Arbash Meinel, #243536)
+
+* ``check`` handles the split-up .bzr layout correctly, so no longer
+ requires a branch to be present.
+ (Daniel Watkins, #64783)
+
+* Clearer message about how to set the PYTHONPATH if bzrlib can't be
+ loaded.
+ (Martin Pool, #205230)
+
+* Errors about missing libraries are now shown without a traceback,
+ and with a suggestion to install the library. The full traceback is
+ still in ``.bzr.log`` and can be shown with ``-Derror``.
+ (Martin Pool, #240161)
+
+* Fetch from a stacked branch copies all required data.
+ (Aaron Bentley, #248506)
+
+* Handle URLs such as ftp://user@host.com@www.host.com where the user
+ name contains an @.
+ (Neil Martinsen-Burrell, #228058)
+
+* ``needs_read_lock`` and ``needs_write_lock`` now suppress an error during
+ ``unlock`` if there was an error in the original function. This helps
+ most when there is a failure with a smart server action, since often the
+ connection closes and we cannot unlock.
+ (Andrew Bennetts, John Arbash Meinel, #125784)
+
+* Obsolete hidden command ``bzr fetch`` removed.
+ (Martin Pool, #172870)
+
+* Raise the correct exception when doing ``-rbefore:0`` or ``-c0``.
+ (John Arbash Meinel, #239933)
+
+* You can now compare file revisions in Windows diff programs from
+ Cygwin Bazaar.
+ (Matt McClure, #209281)
+
+* revision_history now tolerates mainline ghosts for Branch format 6.
+ (Aaron Bentley, #235055)
+
+* Set locale from environment for third party libs.
+ (Martin von Gagern, #128496)
+
+Documentation
+*************
+
+* Added *Using stacked branches* to the User Guide.
+ (Ian Clatworthy)
+
+* Updated developer documentation.
+ (Martin Pool)
+
+Testing
+*******
+
+* ``-Dmemory`` will cause /proc/PID/status to be catted before bzr
+ exits, allowing low-key analysis of peak memory use. (Robert Collins)
+
+* ``TestCaseWithTransport.make_branch_and_tree`` tries harder to return
+ a tree with a ``branch`` attribute of the right format. This was
+ preventing some ``RemoteBranch`` tests from actually running with
+ ``RemoteBranch`` instances. (Andrew Bennetts)
+
+API Changes
+***********
+
+* Removed ``Repository.text_store``, ``control_store``, etc. Instead,
+ there are new attributes ``texts, inventories, revisions,
+ signatures``, each of which is a ``VersionedFiles``. See the
+ Repository docstring for more details.
+ (Robert Collins)
+
+* ``Branch.pull`` now accepts an ``_override_hook_target`` optional
+ parameter. If you have a subclass of ``Branch`` that overrides
+ ``pull`` then you should add this parameter. (Andrew Bennetts)
+
+* ``bzrlib.check.check()`` has been deprecated in favour of the more
+ aptly-named ``bzrlib.check.check_branch()``.
+ (Daniel Watkins)
+
+* ``Tree.print_file`` and ``Repository.print_file`` are deprecated.
+ These methods are bad APIs because they write directly to sys.stdout.
+ bzrlib does not use them internally, and there are no direct tests
+ for them. (Alexander Belchenko)
+
+Internals
+*********
+
+* ``cat`` command no longer uses ``Tree.print_file()`` internally.
+ (Alexander Belchenko)
+
+* New class method ``BzrDir.open_containing_tree_branch_or_repository``
+ which eases the discovery of the tree, the branch and the repository
+ containing a given location.
+ (Daniel Watkins)
+
+* New ``versionedfile.KeyMapper`` interface to abstract out the access to
+ underlying .knit/.kndx etc files in repositories with partitioned
+ storage. (Robert Collins)
+
+* Obsolete developer-use command ``weave-join`` has been removed.
+ (Robert Collins)
+
+* ``RemoteToOtherFetcher`` and ``get_data_stream_for_search`` removed,
+ to support new ``VersionedFiles`` layering.
+ (Robert Collins)
+
+
+bzr 1.6beta2
+############
+
+:Released: 2008-06-10
+
+This release contains further progress towards our 1.6 goals of shallow
+repositories, and contains a fix for some user-affecting bugs in the
+repository layer. Building working trees during checkout and branch is
+now faster.
+
+Bug Fixes
+*********
+
+* Avoid KnitCorrupt error extracting inventories from some repositories.
+ (The data is not corrupt; an internal check is detecting a problem
+ reading from the repository.)
+ (Martin Pool, Andrew Bennetts, Robert Collins, #234748)
+
+* ``bzr status`` was breaking if you merged the same revision twice.
+ (John Arbash Meinel, #235407)
+
+* Fix infinite loop consuming 100% CPU when a connection is lost while
+ reading a response body via the smart protocol v1 or v2.
+ (Andrew Bennetts)
+
+* Inserting a bundle which changes the contents of a file with no trailing
+ end of line, causing a knit snapshot in a 'knits' repository will no longer
+ cause KnitCorrupt. (Robert Collins)
+
+* ``RemoteBranch.pull`` needs to return the ``self._real_branch``'s
+ pull result. It was instead just returning None, which breaks ``bzr
+ pull``. (John Arbash Meinel, #238149)
+
+* Sanitize branch nick before using it as an attachment filename in
+ ``bzr send``. (Lukáš Lalinský, #210218)
+
+* Squash ``inv_entry.symlink_target`` to a plain string when
+ generating DirState details. This prevents from getting a
+ ``UnicodeError`` when you have symlinks and non-ascii filenames.
+ (John Arbash Meinel, #135320)
+
+Improvements
+************
+
+* Added the 'alias' command to set/unset and display aliases. (Tim Penhey)
+
+* ``added``, ``modified``, and ``unknowns`` behaviour made consistent (all three
+ now quote paths where required). Added ``--null`` option to ``added`` and
+ ``modified`` (for null-separated unknowns, use ``ls --unknown --null``)
+ (Adrian Wilkins)
+
+* Faster branching (1.09x) and lightweight checkouts (1.06x) on large trees.
+ (Ian Clatworthy, Aaron Bentley)
+
+Documentation
+*************
+
+* Added *Bazaar Zen* section to the User Guide. (Ian Clatworthy)
+
+Testing
+*******
+
+* Fix the test HTTPServer to be isolated from chdir calls made while it is
+ running, allowing it to be used in blackbox tests. (Robert Collins)
+
+API Changes
+***********
+
+* ``WorkingTree.set_parent_(ids/trees)`` will now filter out revisions
+ which are in the ancestry of other revisions. So if you merge the same
+ tree twice, or merge an ancestor of an existing merge, it will only
+ record the newest. (If you merge a descendent, it will replace its
+ ancestor). (John Arbash Meinel, #235407)
+
+* ``RepositoryPolicy.__init__`` now requires stack_on and stack_on_pwd,
+ through the derived classes do not. (Aaron Bentley)
+
+Internals
+*********
+
+* ``bzrlib.bzrdir.BzrDir.sprout`` now accepts ``stacked`` to control
+ creating stacked branches. (Robert Collins)
+
+* Knit record serialisation is now stricter on what it will accept, to
+ guard against potential internal bugs, or broken input. (Robert Collins)
+
+bzr 1.6beta1
+############
+
+:Released: 2008-06-02
+
+Commands that work on the revision history such as push, pull, missing,
+uncommit and log are now substantially faster. This release adds a
+translation of some of the user documentation into Spanish. (Contributions of
+other translations would be very welcome.) Bazaar 1.6beta1 adds a new network
+protocol which is used by default and which allows for more efficient transfers
+and future extensions.
+
+
+Notes When Upgrading
+********************
+
+* There is a new version of the network protocol used for bzr://, bzr+ssh://
+ and bzr+http:// connections. This will allow more efficient requests and
+ responses, and more graceful fallback when a server is too old to
+ recognise a request from a more recent client. Bazaar 1.6 will
+ interoperate with 0.16 and later versions, but servers should be upgraded
+ when possible. Bazaar 1.6 no longer interoperates with 0.15 and earlier via
+ these protocols. Use alternatives like SFTP or upgrade those servers.
+ (Andrew Bennetts, #83935)
+
+Changes
+*******
+
+* Deprecation warnings will not be suppressed when running ``bzr selftest``
+ so that developers can see if their code is using deprecated functions.
+ (John Arbash Meinel)
+
+Features
+********
+
+* Adding ``-Derror`` will now display a traceback when a plugin fails to
+ load. (James Westby)
+
+Improvements
+************
+
+* ``bzr branch/push/pull -r XXX`` now have a helper function for finding
+ the revno of the new revision (``Graph.find_distance_to_null``). This
+ should make something like ``bzr branch -r -100`` in a shared, no-trees
+ repository much snappier. (John Arbash Meinel)
+
+* ``bzr log --short -r X..Y`` no longer needs to access the full revision
+ history. This makes it noticeably faster when logging the last few
+ revisions. (John Arbash Meinel)
+
+* ``bzr ls`` now accepts ``-V`` as an alias for ``--versioned``.
+ (Jerad Cramp, #165086)
+
+* ``bzr missing`` uses the new ``Graph.find_unique_ancestors`` and
+ ``Graph.find_differences`` to determine missing revisions without having
+ to search the whole ancestry. (John Arbash Meinel, #174625)
+
+* ``bzr uncommit`` now uses partial history access, rather than always
+ extracting the full revision history for a branch. This makes it
+ resolve the appropriate revisions much faster (in testing it drops
+ uncommit from 1.5s => 0.4s). It also means ``bzr log --short`` is one
+ step closer to not using full revision history.
+ (John Arbash Meinel, #172649)
+
+Bugfixes
+********
+
+* ``bzr merge --lca`` should handle when two revisions have no common
+ ancestor other than NULL_REVISION. (John Arbash Meinel, #235715)
+
+* ``bzr status`` was breaking if you merged the same revision twice.
+ (John Arbash Meinel, #235407)
+
+* ``bzr push`` with both ``--overwrite`` and ``-r NNN`` options no longer
+ fails. (Andrew Bennetts, #234229)
+
+* Correctly track the base URL of a smart medium when using bzr+http://
+ URLs, which was causing spurious "No repository present" errors with
+ branches in shared repositories accessed over bzr+http.
+ (Andrew Bennetts, #230550)
+
+* Define ``_remote_is_at_least_1_2`` on ``SmartClientMedium`` so that all
+ implementations have the attribute. Fixes 'PyCurlTransport' object has no
+ attribute '_remote_is_at_least_1_2' attribute errors.
+ (Andrew Bennetts, #220806)
+
+* Failure to delete an obsolete pack file should just give a warning
+ message, not a fatal error. It may for example fail if the file is still
+ in use by another process.
+ (Martin Pool)
+
+* Fix MemoryError during large fetches over HTTP by limiting the amount of
+ data we try to read per ``recv`` call. The problem was observed with
+ Windows and a proxy, but might affect other environments as well.
+ (Eric Holmberg, #215426)
+
+* Handle old merge directives correctly in Merger.from_mergeable. Stricter
+ get_parent_map requirements exposed a latent bug here. (Aaron Bentley)
+
+* Issue a warning and ignore passwords declared in authentication.conf when
+ used for an SSH scheme (sftp:// or bzr+ssh://).
+ (Vincent Ladeuil, #203186)
+
+* Make both HTTP implementations raise appropriate exceptions on 403
+ Forbidden when POSTing smart requests.
+ (Vincent Ladeuil, #230223)
+
+* Properly *title* header names in HTTP requests instead of capitalizing
+ them.
+ (Vincent Ladeuil, #229076)
+
+* The "Unable to obtain lock" error message now also suggests using
+ ``bzr break-lock`` to fix it. (Martin Albisetti, #139202)
+
+* Treat an encoding of '' as ascii; this can happen when bzr is run
+ under vim on Mac OS X.
+ (Neil Martinsen-Burrell)
+
+* ``VersionedFile.make_mpdiffs()`` was raising an exception that wasn't in
+ scope. (Daniel Fischer #235687)
+
+Documentation
+*************
+
+* Added directory structure and started translation of docs in spanish.
+ (Martin Albisetti, Lucio Albenga)
+
+* Incorporate feedback from Jelmer Vernooij and Neil Martinsen-Burrell
+ on the plugin and integration chapters of the User Guide.
+ (Ian Clatworthy)
+
+* More Bazaar developer documentation about packaging and release process,
+ and about use of Python reprs.
+ (Martin Pool, Martin Albisetti)
+
+* Updated Tortise strategy document. (Mark Hammond)
+
+Testing
+*******
+
+* ``bzrlib.tests.adapt_tests`` was broken and unused - it has been fixed.
+ (Robert Collins)
+
+* Fix the test HTTPServer to be isolated from chdir calls made while it is
+ running, allowing it to be used in blackbox tests. (Robert Collins)
+
+* New helper function for splitting test suites
+ ``split_suite_by_condition``. (Robert Collins)
+
+Internals
+*********
+
+* ``Branch.missing_revisions`` has been deprecated. Similar functionality
+ can be obtained using ``bzrlib.missing.find_unmerged``. The api was
+ fairly broken, and the function was unused, so we are getting rid of it.
+ (John Arbash Meinel)
+
+API Changes
+***********
+
+* ``Branch.abspath`` is deprecated; use the Tree or Transport
+ instead. (Martin Pool)
+
+* ``Branch.update_revisions`` now takes an optional ``Graph``
+ object. This can be used by ``update_revisions`` when it is
+ checking ancestry, and allows callers to prefer request to go to a
+ local branch. (John Arbash Meinel)
+
+* Branch, Repository, Tree and BzrDir should expose a Transport as an
+ attribute if they have one, rather than having it indirectly accessible
+ as ``.control_files._transport``. This doesn't add a requirement
+ to support a Transport in cases where it was not needed before;
+ it just simplifies the way it is reached. (Martin Pool)
+
+* ``bzr missing --mine-only`` will return status code 0 if you have no
+ new revisions, but the remote does. Similarly for ``--theirs-only``.
+ The new code only checks one side, so it doesn't know if the other
+ side has changes. This seems more accurate with the request anyway.
+ It also changes the output to print '[This|Other] branch is up to
+ date.' rather than displaying nothing. (John Arbash Meinel)
+
+* ``LockableFiles.put_utf8``, ``put_bytes`` and ``controlfilename``
+ are now deprecated in favor of using Transport operations.
+ (Martin Pool)
+
+* Many methods on ``VersionedFile``, ``Repository`` and in
+ ``bzrlib.revision`` deprecated before bzrlib 1.5 have been removed.
+ (Robert Collins)
+
+* ``RevisionSpec.wants_revision_history`` can be set to False for a given
+ ``RevisionSpec``. This will disable the existing behavior of passing in
+ the full revision history to ``self._match_on``. Useful for specs that
+ don't actually need access to the full history. (John Arbash Meinel)
+
+* The constructors of ``SmartClientMedium`` and its subclasses now require a
+ ``base`` parameter. ``SmartClientMedium`` implementations now also need
+ to provide a ``remote_path_from_transport`` method. (Andrew Bennetts)
+
+* The default permissions for creating new files and directories
+ should now be obtained from ``BzrDir._get_file_mode()`` and
+ ``_get_dir_mode()``, rather than from LockableFiles. The ``_set_file_mode``
+ and ``_set_dir_mode`` variables on LockableFiles which were advertised
+ as a way for plugins to control this are no longer consulted.
+ (Martin Pool)
+
+* ``VersionedFile.join`` is deprecated. This method required local
+ instances of both versioned file objects and was thus hostile to being
+ used for streaming from a smart server. The new get_record_stream and
+ insert_record_stream are meant to efficiently replace this method.
+ (Robert Collins)
+
+* ``WorkingTree.set_parent_(ids/trees)`` will now filter out revisions
+ which are in the ancestry of other revisions. So if you merge the same
+ tree twice, or merge an ancestor of an existing merge, it will only
+ record the newest. (If you merge a descendent, it will replace its
+ ancestor). (John Arbash Meinel, #235407)
+
+* ``WorkingTreeFormat2.stub_initialize_remote`` is now private.
+ (Martin Pool)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.7.txt b/doc/en/release-notes/bzr-1.7.txt
new file mode 100644
index 0000000..349641b
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.7.txt
@@ -0,0 +1,282 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.7.1
+#########
+
+:Released: 2008-10-01
+
+No changes from 1.7.1rc1.
+
+
+bzr 1.7.1rc1
+############
+
+:Released: 2008-09-24
+
+This release just includes an update to how the merge algorithm handles
+file paths when we encounter complex history.
+
+Features
+********
+
+* If we encounter a criss-cross in history, use information from
+ direct Least Common Ancestors to resolve inventory shape (locations
+ of files, adds, deletes, etc). This is similar in concept to using
+ ``--lca`` for merging file texts, only applied to paths.
+ (John Arbash Meinel)
+
+
+bzr 1.7
+#######
+
+:Released: 2008-09-23
+
+This release includes many bug fixes and a few performance and feature
+improvements. ``bzr rm`` will now scan for missing files and remove them,
+like how ``bzr add`` scans for unknown files and adds them. A bit more
+polish has been applied to the stacking code. The b-tree indexing code has
+been brought in, with an eye on using it in a future repository format.
+There are only minor installer changes since bzr-1.7rc2.
+
+Features
+********
+
+* Some small updates to the win32 installer. Include localization
+ files found in plugins, and include the builtin distutils as part of
+ packaging qbzr. (Mark Hammond)
+
+
+bzr 1.7rc2
+##########
+
+:Released: 2008-09-17
+
+A few bug fixes from 1.7rc1. The biggest change is a new
+``RemoteBranch.get_stacked_on_url`` RPC. This allows clients that are
+trying to access a Stacked branch over the smart protocol, to properly
+connect to the stacked-on location.
+
+Bug Fixes
+*********
+
+* Branching from a shared repository on a smart server into a new
+ repository now preserves the repository format.
+ (Andrew Bennetts, #269214)
+
+* Branching from a stacked branch via ``bzr+ssh`` can properly connect
+ to the stacked-on branch. (Martin Pool, #261315)
+
+* ``bzr init`` no longer re-opens the BzrDir multiple times.
+ (Vincent Ladeuil)
+
+* Fix '_in_buffer' AttributeError when using the -Dhpss debug flag.
+ (Andrew Bennetts)
+
+
+bzr 1.7rc1
+##########
+
+:Released: 2008-09-09
+
+This release candidate for bzr 1.7 has several bug fixes and a few
+performance and feature improvements. ``bzr rm`` will now scan for
+missing files and remove them, like how ``bzr add`` scans for unknown
+files and adds them. A bit more polish has been applied to the stacking
+code. The b-tree indexing code has been brought in, with an eye on using
+it in a future repository format.
+
+
+Changes
+*******
+
+* ``bzr export`` can now export a subdirectory of a project.
+ (Robert Collins)
+
+* ``bzr remove-tree`` will now refuse to remove a tree with uncommitted
+ changes, unless the ``--force`` option is specified.
+ (Lukáš Lalinský, #74101)
+
+* ``bzr rm`` will now scan for files that are missing and remove just
+ them automatically, much as ``bzr add`` scans for new files that
+ are not ignored and adds them automatically. (Robert Collins)
+
+Features
+********
+
+* Support for GSSAPI authentication when using FTP as documented in
+ RFC2228. (Jelmer Vernooij, #49623)
+
+* Add support for IPv6 in the smart server. (Jelmer Vernooij, #165014)
+
+Improvements
+************
+
+* A URL like ``log+file:///tmp`` will log all access to that Transport
+ to ``.bzr.log``, which may help in debugging or profiling.
+ (Martin Pool)
+
+* ``bzr branch`` and ``bzr push`` use the default stacking policy if the
+ branch format supports it. (Aaron Bentley)
+
+* ``bzr init`` and ``bzr init-repo`` will now print out the same as
+ ``bzr info`` if it completed successfully.
+ (Marius Kruger)
+
+* ``bzr uncommit`` logs the old tip revision id, and displays how to
+ restore the branch to that tip using ``bzr pull``. This allows you
+ to recover if you realize you uncommitted the wrong thing.
+ (John Arbash Meinel)
+
+* Fix problems in accessing stacked repositories over ``bzr://``.
+ (Martin Pool, #261315)
+
+* ``SFTPTransport.readv()`` was accidentally using ``list += string``,
+ which 'works', but adds each character separately to the list,
+ rather than using ``list.append(string)``. Fixing this makes the
+ SFTP transport a little bit faster (~20%) and use a bit less memory.
+ (John Arbash Meinel)
+
+* When reading index files, if we happen to read the whole file in a
+ single request treat it as a ``_buffer_all`` request. This happens
+ most often on small indexes over remote transports, where we default
+ to reading 64kB. It saves a round trip for each small index during
+ fetch operations. Also, if we have read more than 50% of an index
+ file, trigger a ``_buffer_all`` on the next request. This works
+ around some inefficiencies because reads don't fall neatly on page
+ boundaries, so we would ignore those bytes, but request them again
+ later. This could trigger a total read size of more than the whole
+ file. (John Arbash Meinel)
+
+Bug Fixes
+*********
+
+* ``bzr rm`` is now aliased to ``bzr del`` for the convenience of svn
+ users. (Robert Collins, #205416)
+
+* Catch the infamous "select/poll returned error" which occurs when
+ pycurl try to send a body request to an HTTP/1.0 server which has
+ already refused to handle the request. (Vincent Ladeuil, #225020)
+
+* Fix ``ObjectNotLocked`` errors when using various commands
+ (including ``bzr cat`` and ``bzr annotate``) in combination with a
+ smart server URL. (Andrew Bennetts, #237067)
+
+* ``FTPTransport.stat()`` would return ``0000`` as the permission bits
+ for the containing ``.bzr/`` directory (it does not implement
+ permissions). This would cause us to set all subdirectories to
+ ``0700`` and files to ``0600`` rather than leaving them unmodified.
+ Now we ignore ``0000`` as the permissions and assume they are
+ invalid. (John Arbash Meinel, #259855)
+
+* Merging from a previously joined branch will no longer cause
+ a traceback. (Jelmer Vernooij, #203376)
+
+* Pack operations on windows network shares will work even with large
+ files. (Robert Collins, #255656)
+
+* Running ``bzr st PATH_TO_TREE`` will no longer suppress merge
+ status. Status is also about 7% faster on mozilla sized trees
+ when the path to the root of the tree has been given. Users of
+ the internal ``show_tree_status`` function should be aware that
+ the show_pending flag is now authoritative for showing pending
+ merges, as it was originally. (Robert Collins, #255204)
+
+* Set valid default _param_name for Option so that ListOption can embed
+ '-' in names. (Vincent Ladeuil, #263249)
+
+* Show proper error rather than traceback when an unknown revision
+ id is specified to ``bzr cat-revision``. (Jelmer Vernooij, #175569)
+
+* Trailing text in the dirstate file could cause the C dirstate parser
+ to try to allocate an invalid amount of memory. We now properly
+ check and test for parsing a dirstate with invalid trailing data.
+ (John Arbash Meinel, #186014)
+
+* Unexpected error responses from a smart server no longer cause the
+ client to traceback. (Andrew Bennetts, #263527)
+
+* Use a Windows api function to get a Unicode host name, rather than
+ assuming the host name is ascii.
+ (Mark Hammond, John Arbash Meinel, #256550)
+
+* ``WorkingTree4`` trees will now correctly report missing-and-new
+ paths in the output of ``iter_changes``. (Robert Collins)
+
+Documentation
+*************
+
+* Updated developer documentation. (Martin Pool)
+
+API Changes
+***********
+
+* Exporters now take 4 parameters. (Robert Collins)
+
+* ``Tree.iter_changes`` will now return False for the content change
+ field when a file is missing in the basis tree and not present in
+ the target tree. Previously it returned True unconditionally.
+ (Robert Collins)
+
+* The deprecated ``Branch.abspath`` and unimplemented
+ ``Branch.rename_one`` and ``Branch.move`` were removed. (Jelmer Vernooij)
+
+* BzrDir.clone_on_transport implementations must now accept a stacked_on
+ parameter. (Aaron Bentley)
+
+* BzrDir.cloning_metadir implementations must now take a require_stacking
+ parameter. (Aaron Bentley)
+
+Testing
+*******
+
+* ``addCleanup`` now takes ``*arguments`` and ``**keyword_arguments``
+ which are then passed to the cleanup callable as it is run. In
+ addition, addCleanup no longer requires that the callables passed to
+ it be unique. (Jonathan Lange)
+
+* Fix some tests that fail on Windows because files are deleted while
+ still in use.
+ (Mark Hammond)
+
+* ``selftest``'s ``--starting-with`` option can now use predefined
+ prefixes so that one can say ``bzr selftest -s bp.loom`` instead of
+ ``bzr selftest -s bzrlib.plugins.loom``. (Vincent Ladeuil)
+
+* ``selftest``'s ``--starting-with`` option now accepts multiple values.
+ (Vincent Ladeuil)
+
+Internals
+*********
+
+* A new plugin interface, ``bzrlib.log.log_adapters``, has been added.
+ This allows dynamic log output filtering by plugins.
+ (Robert Collins)
+
+* ``bzrlib.btree_index`` is now available, providing a b-tree index
+ layer. The design is memory conservative (limited memory cache),
+ faster to seek (approx 100 nodes per page, gives 100-way fan out),
+ and stores compressed pages allowing more keys per page.
+ (Robert Collins, John Arbash Meinel)
+
+* ``bzrlib.diff.DiffTree.show_diff`` now skips changes where the kind
+ is unknown in both source and target.
+ (Robert Collins, Aaron Bentley)
+
+* ``GraphIndexBuilder.add_node`` and ``BTreeBuilder`` have been
+ streamlined a bit. This should make creating large indexes faster.
+ (In benchmarking, it now takes less time to create a BTree index than
+ it takes to read the GraphIndex one.) (John Arbash Meinel)
+
+* Mail clients for `bzr send` are now listed in a registry. This
+ allows plugins to add new clients by registering them with
+ ``bzrlib.mail_client.mail_client_registry``. All of the built-in
+ clients now use this mechanism. (Neil Martinsen-Burrell)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.8.txt b/doc/en/release-notes/bzr-1.8.txt
new file mode 100644
index 0000000..85dc28f
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.8.txt
@@ -0,0 +1,234 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.8
+#######
+
+:Released: 2008-10-16
+
+Bazaar 1.8 includes several fixes that improve working tree performance,
+display of revision logs, and merges. The bzr testsuite now passes on OS
+X and Python 2.6, and almost completely passes on Windows. The
+smartserver code has gained several bug fixes and performance
+improvements, and can now run server-side hooks within an HTTP server.
+
+Bug Fixes
+*********
+
+* Fix "Must end write group" error when another error occurs during
+ ``bzr push``. (Andrew Bennetts, #230902)
+
+Portability
+***********
+
+* Some Pyrex versions require the WIN32 macro defined to compile on
+ that platform. (Alexander Belchenko, Martin Pool, #277481)
+
+
+bzr 1.8rc1
+##########
+
+:Released: 2008-10-07
+
+Changes
+*******
+
+* ``bzr log file`` has been changed. It now uses a different method
+ for determining which revisions to show as merging the changes to
+ the file. It now only shows revisions which merged the change
+ towards your mainline. This simplifies the output, makes it faster,
+ and reduces memory consumption. (John Arbash Meinel)
+
+* ``bzr merge`` now defaults to having ``--reprocess`` set, whenever
+ ``--show-base`` is not supplied. (John Arbash Meinel)
+
+* ``bzr+http//`` will now optionally load plugins and write logs on the
+ server. (Marius Kruger)
+
+* ``bzrlib._dirstate_helpers_c.pyx`` does not compile correctly with
+ Pyrex 0.9.4.1 (it generates C code which causes segfaults). We
+ explicitly blacklist that version of the compiler for that
+ extension. Packaged versions will include .c files created with
+ pyrex >= 0.9.6 so it doesn't effect releases, only users running
+ from the source tree. (John Arbash Meinel, #276868)
+
+Features
+********
+
+* bzr is now compatible with python-2.6. python-2.6 is not yet officially
+ supported (nor released, tests were conducted with the dev version of
+ python-2.6rc2), but all known problems have been fixed. Feedback
+ welcome.
+ (Vincent Ladeuil, #269535)
+
+Improvements
+************
+
+* ``bzr annotate`` will now include uncommitted changes from the local
+ working tree by default. Such uncommitted changes are given the
+ revision number they would get if a commit was done, followed with a
+ ? to indicate that its not actually known. (Robert Collins, #3439)
+
+* ``bzr branch`` now accepts a ``--standalone`` option, which creates a
+ standalone branch regardless of the presence of shared repositories.
+ (Daniel Watkins)
+
+* ``bzr push`` is faster in the case there are no new revisions to
+ push. It is also faster if there are no tags in the local branch.
+ (Andrew Bennetts)
+
+* File changes during a commit will update the tree stat cache.
+ (Robert Collins)
+
+* Location aliases can now accept a trailing path. (Micheal Hudson)
+
+* New hooks ``Lock.hooks`` when LockDirs are acquired and released.
+ (Robert Collins, MartinPool)
+
+* Switching in heavyweight checkouts uses the master branch's context, not
+ the checkout's context. (Adrian Wilkins)
+
+* ``status`` on large trees is now faster, due to optimisations in the
+ walkdirs code. Of particular note, the walkdirs code now performs
+ a temporary ``chdir()`` while reading a single directory; if your
+ platform has non thread-local current working directories (and is
+ not windows which has its own implementation), this may introduce a
+ race condition during concurrent uses of bzrlib. The bzrlib CLI
+ will not encounter this as it is single threaded for working tree
+ operations. (Robert Collins)
+
+* The C extensions now build on python 2.4 (Robert Collins, #271939)
+
+* The ``-Dhpss`` debug flag now reports the number of smart server
+ calls per medium to stderr. This is in addition to the existing
+ detailed logging to the .bzr.log trace file. (Andrew Bennetts)
+
+Bug Fixes
+*********
+
+* Avoid random failures arising from misinterpreted ``errno`` values
+ in ``_readdir_pyx.read_dir``.
+ (Martin Pool, #279381)
+
+* Branching from a shared repository on a smart server into a new
+ repository now preserves the repository format.
+ (Andrew Bennetts, #269214)
+
+* ``bzr log`` now accepts a ``--change`` option.
+ (Vincent Ladeuil, #248427)
+
+* ``bzr missing`` now accepts an ``--include-merges`` option.
+ (Vincent Ladeuil, #233817)
+
+* Don't try to filter (internally) '.bzr' from the files to be deleted if
+ it's not there.
+ (Vincent Ladeuil, #272648)
+
+* Fix '_in_buffer' AttributeError when using the -Dhpss debug flag.
+ (Andrew Bennetts)
+
+* Fix TooManyConcurrentRequests errors caused by a connection failure
+ when doing ``bzr pull`` or ``bzr merge`` from a ``bzr+ssh`` URL.
+ (Andrew Bennetts, #246233)
+
+* Fixed ``bzr st -r branch:PATH_TO_BRANCH`` where the other branch
+ is in a different repository than the current one.
+ (Lukáš Lalinský, #144421)
+
+* Make the first line of the manpage preamble a comment again.
+ (David Futcher, #242106)
+
+* Remove use of optional parameter in GSSAPI FTP support, since
+ it breaks newer versions of Python-Kerberos. (Jelmer Vernooij)
+
+* The autopacking logic will now always create a single new pack from
+ all of the content which it deems is worth moving. This avoids the
+ 'repack a single pack' bug and should result in better packing
+ overall. (John Arbash Meinel, #242510, #172644)
+
+* Trivial documentation fix.
+ (John Arbash Meinel, #270471)
+
+* ``bzr switch`` and ``bzr bind`` will now update the branch nickname if
+ it was previously set. All checkouts will now refer to the bound branch
+ for a nickname if one was not explicitly set.
+ (Marius Kruger, #230903)
+
+Documentation
+*************
+
+* Explain revision/range identifiers. (Daniel Clemente)
+
+API Changes
+***********
+
+* ``CommitBuilder.record_entry_contents`` returns one more element in
+ its result tuple - an optional file system hash for the hash cache
+ to use. (Robert Collins)
+
+* ``dirstate.DirState.update_entry`` will now only calculate the sha1
+ of a file if it is likely to be needed in determining the output
+ of iter_changes. (Robert Collins)
+
+* The PackRepository, RepositoryPackCollection, NewPack classes have a
+ slightly changed interface to support different index types; as a
+ result other users of these classes need to supply the index types
+ they want. (Robert Collins)
+
+Testing
+*******
+
+* ``bzrlib.tests.repository_implementations`` has been renamed to
+ ``bzrlib.tests.per_repository`` so that we have a common structure
+ (and it is shorter). (John Arbash Meinel, #239343)
+
+* ``LocalTransport.abspath()`` now returns a drive letter if the
+ transport has one, fixing numerous tests on Windows.
+ (Mark Hammond)
+
+* PreviewTree is now tested via intertree_implementations.
+ (Aaron Bentley)
+
+* The full test suite is passing again on OSX.
+ (Guillermo Gonzalez, Vincent Ladeuil)
+
+* The full test suite passes when run with ``-Eallow_debug``.
+ (Andrew Bennetts)
+
+Internals
+*********
+
+* A new hook, ``Branch.open``, has been added, which is called when
+ branch objects are opened. (Robert Collins)
+
+* ``bzrlib.osutils._walkdirs_utf8`` has been refactored into common
+ tree walking, and modular directory listing code to aid future
+ performance optimisations and refactoring. (Robert Collins)
+
+* ``bzrlib.trace.debug_memory`` can be used to get a quick memory dump
+ in the middle of processing. It only reports memory if
+ ``/proc/PID/status`` is available. (John Arbash Meinel)
+
+* New method ``RevisionSpec.as_tree`` for representing the revision
+ specifier as a revision tree object. (Lukáš Lalinský)
+
+* New race-free method on MutableTree ``get_file_with_stat`` for use
+ when generating stat cache results. (Robert Collins)
+
+* New win32utils.get_local_appdata_location() provides access to a local
+ directory for storing data. (Mark Hammond)
+
+* To be compatible with python-2.6 a few new rules should be
+ observed. 'message' attribute can't be used anymore in exception
+ classes, 'sha' and 'md5' modules have been deprecated (use
+ osutils.[md5|sha]), object__init__ and object.__new__ don't accept
+ parameters anymore.
+ (Vincent Ladeuil)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-1.9.txt b/doc/en/release-notes/bzr-1.9.txt
new file mode 100644
index 0000000..7b87f16
--- /dev/null
+++ b/doc/en/release-notes/bzr-1.9.txt
@@ -0,0 +1,154 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 1.9
+#######
+
+:Released: 2008-11-07
+
+This release of Bazaar adds a new repository format, ``1.9``, with smaller
+and more efficient index files. This format can be specified when
+creating a new repository, or used to losslessly upgrade an existing
+repository. bzr 1.9 also speeds most operations over the smart server
+protocol, makes annotate faster, and uses less memory when making
+checkouts or pulling large amounts of data.
+
+Bug Fixes
+*********
+
+* Fix "invalid property value 'branch-nick' for None" regression with
+ branches bound to svn branches. (Martin Pool, #293440)
+
+* Fix SSL/https on Python2.6. (Vincent Ladeuil, #293054)
+
+* ``SFTPTransport.readv()`` had a bug when requests were out-of-order.
+ This only triggers some-of-the-time on Knit format repositories.
+ (John Arbash Meinel, #293746)
+
+
+bzr 1.9rc1
+##########
+
+:Released: 2008-10-31
+
+New Features
+************
+
+* New Branch hook ``transform_fallback_location`` allows a function to
+ be called when looking up the stacked source. (Michael Hudson)
+
+* New repository formats ``1.9`` and ``1.9-rich-root``. These have all
+ the functionality of ``1.6``, but use the new btree indexes.
+ These indexes are both smaller and faster for access to historical
+ information. (John Arbash Meinel)
+
+Improvements
+************
+
+* ``BTreeIndex`` code now is able to prefetch extra pages to help tune
+ the tradeoff between bandwidth and latency. Should be tuned
+ appropriately to not impact commands which need minimal information,
+ but provide a significant boost to ones that need more context. Only
+ has a direct impact on the ``--development2`` format which uses
+ btree's for the indexes. (John Arbash Meinel)
+
+* ``bzr dump-btree`` is a hidden command introduced to allow dumping
+ the contents of a compressed btree file. (John Arbash Meinel)
+
+* ``bzr pack`` now tells the index builders to optimize for size. For
+ btree index repositories, this can save 25% of the index size
+ (mostly in the text indexes). (John Arbash Meinel)
+
+* ``bzr push`` to an existing branch or repository on a smart server
+ is faster, due to Bazaar making more use of the ``get_parent_map``
+ RPC when querying the remote branch's revision graph.
+ (Andrew Bennetts)
+
+* default username for bzr+ssh:// and sftp:// can be configured in
+ authentication.conf. (Aaron Bentley)
+
+* launchpad-login now provides a default username for bzr+ssh and SFTP
+ URLs, allowing username-free URLs to work for everyone. (Aaron Bentley)
+
+* ``lp:`` lookups no longer include usernames, making them shareable and
+ shorter. (Aaron Bentley)
+
+* New ``PackRepository.autopack`` smart server RPC, which does
+ autopacking entirely on the server. This is much faster than
+ autopacking via plain file methods, which downloads a large amount
+ of pack data and then re-uploads the same pack data into a single
+ file. This fixes a major (although infrequent) cause of lengthy
+ delays when using a smart server. For example, pushing the 10th
+ revision to a repository with 9 packs now takes 44 RPCs rather than
+ 179, and much less bandwidth too. This requires Bazaar 1.9 on both
+ the client and the server, otherwise the client will fallback to the
+ slower method. (Andrew Bennetts)
+
+Bug Fixes
+*********
+
+* A failure to load a plugin due to an IncompatibleAPI exception is
+ now correctly reported. (Robert Collins, #279451)
+
+* API versioning support now has a multiple-version checking api
+ ``require_any_api``. (Robert Collins, #279447)
+
+* ``bzr branch --stacked`` from a smart server to a standalone branch
+ works again. This fixes a regression in 1.7 and 1.8.
+ (Andrew Bennetts, #270397)
+
+* ``bzr co`` uses less memory. It used to unpack the entire WT into
+ memory before writing it to disk. This was a little bit faster, but
+ consumed lots of memory. (John Arbash Meinel, #269456)
+
+* ``bzr missing --quiet`` no longer prints messages about whether
+ there are missing revisions. The exit code indicates whether there
+ were or not. (Martin Pool, #284748)
+
+* Fixes to the ``annotate`` code. The fast-path which re-used the
+ stored deltas was accidentally disabled all the time, instead of
+ only when a branch was stacked. Second, the code would accidentally
+ re-use a delta even if it wasn't against the left-parent, this
+ could only happen if ``bzr reconcile`` decided that the parent
+ ordering was incorrect in the file graph. (John Arbash Meinel)
+
+* "Permission denied" errors that occur when pushing a new branch to a
+ smart server no longer cause tracebacks. (Andrew Bennetts, #278673)
+
+* Some compatibility fixes for building the extensions with MSVC and
+ for python2.4. (John Arbash Meinel, #277484)
+
+* The index logic is now able to reload the list of pack files if and
+ index ends up disappearing. We still don't reload if the pack data
+ itself goes missing after checking the index. This bug appears as a
+ transient failure (file not found) when another process is writing
+ to the repository. (John Arbash Meinel, #153786)
+
+* ``bzr switch`` and ``bzr bind`` will now update the branch nickname if
+ it was previously set. All checkouts will now refer to the bound branch
+ for a nickname if one was not explicitly set.
+ (Marius Kruger, #230903)
+
+Documentation
+*************
+
+* Improved hook documentation. (Michael Ernst)
+
+API Changes
+***********
+
+* commands.plugins_cmds is now a CommandRegistry, not a dict.
+
+Internals
+*********
+
+* New AuthenticationConfig.set_credentials method allows easy programmatic
+ configuration of authetication credentials.
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-2.0.txt b/doc/en/release-notes/bzr-2.0.txt
new file mode 100644
index 0000000..e11070b
--- /dev/null
+++ b/doc/en/release-notes/bzr-2.0.txt
@@ -0,0 +1,655 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 2.0.7
+#########
+
+:2.0.7: NOT RELEASED YET
+
+Compatibility Breaks
+********************
+
+* Launchpad has announced that the ``edge.launchpad.net`` instance is
+ deprecated and may be shut down in the future
+ <http://blog.launchpad.net/general/edge-is-deprecated>. Bazaar has therefore
+ been updated in this release to talk to the main (``launchpad.net``) servers,
+ rather than the ``edge`` ones. (Vincent Ladeuil, #583667)
+
+New Features
+************
+
+Bug Fixes
+*********
+
+* Avoid spurious ValueErrors when autopacking a subset of the repository,
+ and seeing a revision without its related inventory
+ (John Arbash Meinel, #437003)
+
+* Avoid UnicodeDecodeError in ``bzr add`` with multiple files under a non-ascii
+ path on windows from symlink support addition. (Martin [gz], #686611)
+
+* Fix activity reporting for pycurl when using https with some
+ implementations of curl. (Vincent Ladeuil, #614713)
+
+Improvements
+************
+
+Documentation
+*************
+
+API Changes
+***********
+
+Internals
+*********
+
+Testing
+*******
+
+
+bzr 2.0.6
+#########
+
+:2.0.6: 2010-09-17
+
+The sixth release in our 2.0 series addresses several user-inconvenience
+bugs. None are critical, but upgrading is recommended for all users on
+earlier 2.0 releases.
+
+Bug Fixes
+*********
+
+* Additional merges after an unrelated branch has been merged with its
+ history no longer crash when deleted files are involved.
+ (Vincent Ladeuil, John Arbash Meinel, #375898)
+
+* ``bzr add SYMLINK/FILE`` now works properly when the symlink points to a
+ previously-unversioned directory within the tree: the directory is
+ marked versioned too.
+ (Martin Pool, #192859)
+
+* ``bzr commit SYMLINK`` now works, rather than trying to commit the
+ target of the symlink.
+ (Martin Pool, John Arbash Meinel, #128562)
+
+* ``bzr revert`` now only takes write lock on working tree, instead of on
+ both working tree and branch.
+ (Danny van Heumen, #498409)
+
+* ``bzr upgrade`` now creates the ``backup.bzr`` directory with the same
+ permissions as ``.bzr`` directory on a POSIX OS.
+ (Parth Malwankar, #262450)
+
+* Don't traceback trying to unversion children files of an already
+ unversioned directory. (Vincent Ladeuil, #494221)
+
+* Don't traceback when a lockdir's ``held/info`` file is corrupt (e.g.
+ contains only NUL bytes). Instead warn the user, and allow ``bzr
+ break-lock`` to remove it. (Andrew Bennetts, #619872)
+
+* Fix ``AttributeError on parent.children`` when adding a file under a
+ directory that was a symlink in the previous commit.
+ (Martin Pool, #192859)
+
+* Prevent ``CHKMap.apply_delta`` from generating non-canonical CHK maps,
+ which can result in "missing referenced chk root keys" errors when
+ fetching from repositories with affected revisions.
+ (Andrew Bennetts, #522637)
+
+* Raise ValueError instead of a string exception.
+ (John Arbash Meinel, #586926)
+
+* Reduce peak memory by one copy of compressed text.
+ (John Arbash Meinel, #566940)
+
+* Repositories accessed via a smart server now reject being stacked on a
+ repository in an incompatible format, as is the case when accessing them
+ via other methods. This was causing fetches from those repositories via
+ a smart server (e.g. using ``bzr branch``) to receive invalid data.
+ (Andrew Bennetts, #562380)
+
+* Selftest with versions of subunit that support ``stopTestRun`` will no longer
+ error. This error was caused by 2.0 not being updated when upstream
+ python merged the end of run patch, which chose ``stopTestRun`` rather than
+ ``done``. (Robert Collins, #571437)
+
+* When passing a file to ``UTF8DirReader`` make sure to close the current
+ directory file handle after the chdir fails. Otherwise when passing many
+ filenames into a command line ``bzr status`` we would leak descriptors.
+ (John Arbash Meinel, #583486)
+
+
+Testing
+*******
+
+* ``build_tree_contents`` can create symlinks.
+ (Martin Pool, John Arbash Meinel)
+
+
+bzr 2.0.5
+#########
+
+:2.0.5: 2010-03-23
+
+This fifth release in our 2.0 series addresses several user-inconvenience
+bugs. None are critical, but upgrading is recommended for all users on
+earlier 2.0 releases.
+
+Bug Fixes
+*********
+
+* Avoid ``malloc(0)`` in ``patiencediff``, which is non-portable.
+ (Martin Pool, #331095)
+
+* Concurrent autopacking is more resilient to already-renamed pack files.
+ If we find that a file we are about to obsolete is already obsoleted, we
+ do not try to rename it, and we leave the file in ``obsolete_packs``.
+ The code is also fault tolerant if a file goes missing, assuming that
+ another process already removed the file.
+ (John Arbash Meinel, Gareth White, #507557)
+
+* Cope with the lockdir ``held/info`` file being empty, which seems to
+ happen fairly often if the process is suddenly interrupted while taking
+ a lock.
+ (Martin Pool, #185103)
+
+* Give the warning about potentially slow cross-format fetches much
+ earlier on in the fetch operation. Don't show this message during
+ upgrades, and show the correct format indication for remote
+ repositories.
+ (Martin Pool, #456077, #515356, #513157)
+
+* Handle renames correctly when there are files or directories that
+ differ only in case. (Chris Jones, Martin Pool, #368931)
+
+* If ``bzr push --create-prefix`` triggers an unexpected ``NoSuchFile``
+ error, report that error rather than failing with an unhelpful
+ ``UnboundLocalError``.
+ (Andrew Bennetts, #423563)
+
+* Running ``bzr`` command without any arguments now shows bzr
+ version number along with rest of the help text.
+ (Parth Malwankar, #369501)
+
+* Use osutils.O_NOINHERIT for some files on win32 to avoid PermissionDenied
+ errors.
+ (Inada Naoki, #524560)
+
+Documentation
+*************
+
+* Added ``location-alias`` help topic.
+ (Andrew Bennetts, #337834)
+
+* Fixed CHM generation by moving the NEWS section template into
+ a separate file. (Ian Clatworthy, #524184)
+
+
+bzr 2.0.4
+#########
+
+:Codename: smooth sailing
+:2.0.4: 2010-01-21
+
+The fourth bugfix-only release in the 2.0 series contains more than a
+dozen bugfixes relative to 2.0.3. The primary focus is on handling
+interruptions and concurrent operations more cleanly, there is also a fair
+improvement to ``bzr export`` when exporting a remote branch.
+
+
+Bug Fixes
+*********
+
+* ``bzr annotate`` on another branch with ``-r branch:...`` no longer
+ fails with an ``ObjectNotLocked`` error. (Andrew Bennetts, #496590)
+
+* ``bzr export dir`` now requests all file content as a record stream,
+ rather than requsting the file content one file-at-a-time. This can make
+ exporting over the network significantly faster (54min => 9min in one
+ case). (John Arbash Meinel, #343218)
+
+* ``bzr serve`` no longer slowly leaks memory. The compiled
+ ``bzrlib.bencode.Encoder()`` class was using ``__del__`` to cleanup and
+ free resources, and it should have been using ``__dealloc__``.
+ This will likely have an impact on any other process that is serving for
+ an extended period of time. (John Arbash Meinel, #494406)
+
+* Check for SIGINT (Ctrl-C) and other signals immediately if ``readdir``
+ returns ``EINTR`` by calling ``PyErr_CheckSignals``. This affected the
+ optional ``_readdir_pyx`` extension. (Andrew Bennetts, #495023)
+
+* Concurrent autopacks will no longer lose a newly created pack file.
+ There was a race condition, where if the reload happened at the right
+ time, the second packer would forget the name of the newly added pack
+ file. (John Arbash Meinel, Gareth White, #507566)
+
+* Give a clearer message if the lockdir disappears after being apparently
+ successfully taken. (Martin Pool, #498378)
+
+* Give a warning when fetching between repositories (local or remote) with
+ sufficiently different formats that the content will need to be
+ serialized (ie ``InterDifferingSerializer`` or ``inventory-deltas``), so
+ the user has a clue that upgrading could make it faster.
+ (Martin Pool, #456077)
+
+* If we fail to open ``~/.bzr.log`` write a clear message to stderr rather
+ than using ``warning()``. The log file is opened before logging is set
+ up, and it leads to very confusing: 'no handlers for "bzr"' messages for
+ users, rather than something nicer.
+ (John Arbash Meinel, Barry Warsaw, #503886)
+
+* Refuse to build with any Pyrex 0.9.4 release, as they have known bugs.
+ (Martin Pool, John Arbash Meinel, #449372)
+
+* ``setup.py bdist_rpm`` now properly finds extra files needed for the
+ build. (there is still the distutils bug
+ http://bugs.python.org/issue644744) (Joe Julian, #175839)
+
+* The 2a format wasn't properly restarting autopacks when something
+ changed underneath it (like another autopack). Now concurrent
+ autopackers will properly succeed. (John Arbash Meinel, #495000)
+
+* ``TreeTransform`` can now handle when a delta says that the file id for
+ the tree root changes. Rather than trying to rename your working
+ directory, or failing early saying that you can't have multiple
+ tree roots. This also fixes revert, update, and pull when the root id
+ changes. (John Arbash Meinel, #494269, #504390)
+
+* ``_update_current_block`` no longer suppresses exceptions, so ^C at just
+ the right time will get propagated, rather than silently failing to move
+ the block pointer. (John Arbash Meinel, Gareth White, #495023)
+
+Testing
+*******
+
+* We have a new ``test_source`` that ensures all pyrex ``cdef`` functions
+ handle exceptions somehow. (Possibly by setting ``# cannot_raise``
+ rather than an ``except ?:`` clause.) This should help prevent bugs like
+ bug #495023. (John Arbash Meinel)
+
+
+bzr 2.0.3
+#########
+
+:Codename: little italy
+:2.0.3: 2009-12-14
+
+
+The third stable release of Bazaar has a small handful of bugfixes. As
+expected, this has no internal or external compatibility changes versus
+2.0.2 (or 2.0.0).
+
+Bug Fixes
+*********
+
+* ``bzr push --use-existing-dir`` no longer crashes if the directory
+ exists but contains an invalid ``.bzr`` directory.
+ (Andrew Bennetts, #423563)
+
+* Content filters are now applied correctly after pull, merge and switch.
+ (Ian Clatworthy, #385879)
+
+* Fix a potential segfault in the groupcompress hash map handling code.
+ When inserting new entries, if the final hash bucket was empty, we could
+ end up trying to access if ``(last_entry+1)->ptr == NULL``.
+ (John Arbash Meinel, #490228)
+
+* Improve "Binary files differ" hunk handling. (Aaron Bentley, #436325)
+
+
+bzr 2.0.2
+#########
+
+:Codename: after the scare
+:2.0.2: 2009-11-02
+
+The second in our "let's keep the stable bugfixes flowing" series. As
+expected this has a few (~9) bugfixes relative to 2.0.1, and no major api
+changes or features.
+
+Bug Fixes
+*********
+
+* Avoid "NoneType has no attribute st_mode" error when files disappear
+ from a directory while it's being read. (Martin Pool, #446033)
+
+* Content filters are now applied correctly after revert.
+ (Ian Clatworthy)
+
+* Diff parsing handles "Binary files differ" hunks. (Aaron Bentley, #436325)
+
+* Fetching from stacked pre-2a repository via a smart server no longer
+ fails intermittently with "second push failed to complete".
+ (Andrew Bennetts, #437626)
+
+* Fix typos left after test_selftest refactoring.
+ (Vincent Ladeuil, Matt Nordhoff, #461149)
+
+* Fixed ``ObjectNotLocked`` errors during ``bzr log -r NNN somefile``.
+ (Andrew Bennetts, #445171)
+
+* PreviewTree file names are not limited by the encoding of the temp
+ directory's filesystem. (Aaron Bentley, #436794)
+
+Improvements
+************
+
+* ``bzr log`` now read-locks branches exactly once, so makes better use of
+ data caches. (Andrew Bennetts)
+
+Documentation
+*************
+
+* Filtered views user documentation upgraded to refer to format 2a
+ instead of pre-2.0 formats. (Ian Clatworthy)
+
+
+bzr 2.0.1
+#########
+
+:Codename: Stability First
+:2.0.1: 2009-10-14
+
+The first of our new ongoing bugfix-only stable releases has arrived. It
+includes a collection of 12 bugfixes applied to bzr 2.0.0, but does not
+include any of the feature development in the 2.1.0 series.
+
+
+Bug Fixes
+*********
+
+* ``bzr add`` in a tree that has files with ``\r`` or ``\n`` in the
+ filename will issue a warning and skip over those files.
+ (Robert Collins, #3918)
+
+* bzr will attempt to authenticate with SSH servers that support
+ ``keyboard-interactive`` auth but not ``password`` auth when using
+ Paramiko. (Andrew Bennetts, #433846)
+
+* Fixed fetches from a stacked branch on a smart server that were failing
+ with some combinations of remote and local formats. This was causing
+ "unknown object type identifier 60" errors. (Andrew Bennetts, #427736)
+
+* Fixed ``ObjectNotLocked`` errors when doing some log and diff operations
+ on branches via a smart server. (Andrew Bennetts, #389413)
+
+* Handle things like ``bzr add foo`` and ``bzr rm foo`` when the tree is
+ at the root of a drive. ``osutils._cicp_canonical_relpath`` always
+ assumed that ``abspath()`` returned a path that did not have a trailing
+ ``/``, but that is not true when working at the root of the filesystem.
+ (John Arbash Meinel, Jason Spashett, #322807)
+
+* Hide deprecation warnings for 'final' releases for python2.6.
+ (John Arbash Meinel, #440062)
+
+* Improve the time for ``bzr log DIR`` for 2a format repositories.
+ We had been using the same code path as for <2a formats, which required
+ iterating over all objects in all revisions.
+ (John Arbash Meinel, #374730)
+
+* Make sure that we unlock the tree if we fail to create a TreeTransform
+ object when doing a merge, and there is limbo, or pending-deletions
+ directory. (Gary van der Merwe, #427773)
+
+* Occasional IndexError on renamed files have been fixed. Operations that
+ set a full inventory in the working tree will now go via the
+ apply_inventory_delta code path which is simpler and easier to
+ understand than dirstates set_state_from_inventory method. This may
+ have a small performance impact on operations built on _write_inventory,
+ but such operations are already doing full tree scans, so no radical
+ performance change should be observed. (Robert Collins, #403322)
+
+* Retrieving file text or mtime from a _PreviewTree has good performance when
+ there are many changes. (Aaron Bentley)
+
+* The CHK index pages now use an unlimited cache size. With a limited
+ cache and a large project, the random access of chk pages could cause us
+ to download the entire cix file many times.
+ (John Arbash Meinel, #402623)
+
+* When a file kind becomes unversionable after being added, a sensible
+ error will be shown instead of a traceback. (Robert Collins, #438569)
+
+Documentation
+*************
+
+* Improved README. (Ian Clatworthy)
+
+* Improved upgrade documentation for Launchpad branches.
+ (Barry Warsaw)
+
+
+bzr 2.0.0
+#########
+
+:2.0.0: 2009-09-22
+:Codename: Instant Karma
+
+This release of Bazaar makes the 2a (previously 'brisbane-core') format
+the default when new branches or repositories are created. This format is
+substantially smaller and faster for many operations. Most of the work in
+this release focuses on bug fixes and stabilization, covering both 2a and
+previous formats. (See the Upgrade Guide for information on migrating
+existing projects.)
+
+This release also improves the documentation content and presentation,
+including adding Windows HtmlHelp manuals.
+
+The Bazaar team decided that 2.0 will be a long-term supported release,
+with bugfix-only 2.0.x releases based on it, continuing for at least six
+months or until the following stable release.
+
+Changes from 2.0.0rc2 to final
+******************************
+
+* Officially branded as 2.0.0 rather than 2.0 to clarify between things
+ that "want to happen on the 2.0.x stable series" versus things that want
+ to "land in 2.0.0". (Changes how bzrlib._format_version_tuple() handles
+ micro = 0.) (John Arbash Meinel)
+
+
+bzr 2.0.0rc2
+############
+
+:2.0.0rc2: 2009-09-10
+
+New Features
+************
+
+* Added post_commit hook for mutable trees. This allows the keywords
+ plugin to expand keywords on files changed by the commit.
+ (Ian Clatworthy, #408841)
+
+Bug Fixes
+*********
+
+* Bazaar's native protocol code now correctly handles EINTR, which most
+ noticeably occurs if you break in to the debugger while connected to a
+ bzr+ssh server. You can now can continue from the debugger (by typing
+ 'c') and the process continues. However, note that pressing C-\ in the
+ shell may still kill the SSH process, which is bug 162509, so you must
+ sent a signal to the bzr process specifically, for example by typing
+ ``kill -QUIT PID`` in another shell. (Martin Pool, #341535)
+
+* ``bzr check`` in pack-0.92, 1.6 and 1.9 format repositories will no
+ longer report incorrect errors about ``Missing inventory ('TREE_ROOT', ...)``
+ (Robert Collins, #416732)
+
+* ``bzr info -v`` on a 2a format still claimed that it was a "Development
+ format" (John Arbash Meinel, #424392)
+
+* ``bzr log stacked-branch`` shows the full log including
+ revisions that are in the fallback repository. (Regressed in 2.0rc1).
+ (John Arbash Meinel, #419241)
+
+* Clearer message when Bazaar runs out of memory, instead of a ``MemoryError``
+ traceback. (Martin Pool, #109115)
+
+* Conversion to 2a will create a single pack for all the new revisions (as
+ long as it ran without interruption). This improves both ``bzr upgrade``
+ and ``bzr pull`` or ``bzr merge`` from local branches in older formats.
+ The autopack logic that occurs every 100 revisions during local
+ conversions was not returning that pack's identifier, which resulted in
+ the partial packs created during the conversion not being consolidated
+ at the end of the conversion process. (Robert Collins, #423818)
+
+* Fetches from 2a to 2a are now again requested in 'groupcompress' order.
+ Groups that are seen as 'underutilized' will be repacked on-the-fly.
+ This means that when the source is fully packed, there is minimal
+ overhead during the fetch, but if the source is poorly packed the result
+ is a fairly well packed repository (not as good as 'bzr pack' but
+ good-enough.) (Robert Collins, John Arbash Meinel, #402652)
+
+* Fix a potential segmentation fault when doing 'log' of a branch that had
+ ghosts in its mainline. (Evaluating None as a tuple is bad.)
+ (John Arbash Meinel, #419241)
+
+* ``groupcompress`` sort order is now more stable, rather than relying on
+ ``topo_sort`` ordering. The implementation is now
+ ``KnownGraph.gc_sort``. (John Arbash Meinel)
+
+* Local data conversion will generate correct deltas. This is a critical
+ bugfix vs 2.0rc1, and all 2.0rc1 users should upgrade to 2.0rc2 before
+ converting repositories. (Robert Collins, #422849)
+
+* Network streams now decode adjacent records of the same type into a
+ single stream, reducing layering churn. (Robert Collins)
+
+* Prevent some kinds of incomplete data from being committed to a 2a
+ repository, such as revisions without inventories, a missing chk_bytes
+ record for an inventory, or a missing text referenced by an inventory.
+ (Andrew Bennetts, #423506, #406687)
+
+Documentation
+*************
+
+* Fix assertion error about "_remember_remote_is_before" when pushing to
+ older smart servers.
+ (Andrew Bennetts, #418931)
+
+* Help on hooks no longer says 'Not deprecated' for hooks that are
+ currently supported. (Ian Clatworthy, #422415)
+
+* PDF and CHM (Windows HtmlHelp) formats are now supported for the
+ user documentation. The HTML documentation is better broken up into
+ topics. (Ian Clatworthy)
+
+* The developer and foreign language documents are now separated
+ out so that searching in the HTML and CHM files produces more
+ useful results. (Ian Clatworthy)
+
+* The main table of contents now provides links to the new Migration Docs
+ and Plugins Guide. (Ian Clatworthy)
+
+
+bzr 2.0.0rc1
+############
+
+:Codename: no worries
+:2.0.0rc1: 2009-08-26
+
+Compatibility Breaks
+********************
+
+* The default format for bzr is now ``2a``. This format brings many
+ significant performance and size improvements. bzr can pull from
+ any existing repository into a ``2a`` one, but can only transfer
+ from ``2a`` into ``rich-root`` repositories. The Upgrade guide
+ has more information about this change. (Robert Collins)
+
+* On Windows auto-detection of Putty's plink.exe is disabled.
+ Default SSH client for Windows is paramiko. User still can force
+ usage of plink if explicitly set environment variable BZR_SSH=plink.
+ (#414743, Alexander Belchenko)
+
+New Features
+************
+
+* ``bzr branch --switch`` can now switch the checkout in the current directory
+ to the newly created branch. (Lukáš Lalinský)
+
+Bug Fixes
+*********
+
+* Further tweaks to handling of ``bzr add`` messages about ignored files.
+ (Jason Spashett, #76616)
+
+* Fetches were being requested in 'groupcompress' order, but weren't
+ recombining the groups. Thus they would 'fragment' to get the correct
+ order, but not 'recombine' to actually benefit from it. Until we get
+ recombining to work, switching to 'unordered' fetches avoids the
+ fragmentation. (John Arbash Meinel, #402645)
+
+* Fix a pycurl related test failure on karmic by recognizing an error
+ raised by newer versions of pycurl.
+ (Vincent Ladeuil, #306264)
+
+* Fix a test failure on karmic by making a locale test more robust.
+ (Vincent Ladeuil, #413514)
+
+* Fix IndexError printing CannotBindAddress errors.
+ (Martin Pool, #286871)
+
+* Fix "Revision ... not present" errors when upgrading stacked branches,
+ or when doing fetches from a stacked source to a stacked target.
+ (Andrew Bennetts, #399140)
+
+* ``bzr branch`` of 2a repositories over HTTP is much faster. bzr now
+ batches together small fetches from 2a repositories, rather than
+ fetching only a few hundred bytes at a time.
+ (Andrew Bennetts, #402657)
+
+Improvements
+************
+
+* A better description of the platform is shown in crash tracebacks, ``bzr
+ --version`` and ``bzr selftest``.
+ (Martin Pool, #409137)
+
+* bzr can now (again) capture crash data through the apport library,
+ so that a single human-readable file can be attached to bug reports.
+ This can be disabled by using ``-Dno_apport`` on the command line, or by
+ putting ``no_apport`` into the ``debug_flags`` section of
+ ``bazaar.conf``.
+ (Martin Pool, Robert Collins, #389328)
+
+* ``bzr push`` locally on windows will no longer give a locking error with
+ dirstate based formats. (Robert Collins)
+
+* ``bzr shelve`` and ``bzr unshelve`` now work on windows.
+ (Robert Collins, #305006)
+
+* Commit of specific files no longer prevents using the iter_changes
+ codepath. On 2a repositories, commit of specific files should now be as
+ fast, or slightly faster, than a full commit. (Robert Collins)
+
+* The internal core code that handles specific file operations like
+ ``bzr st FILENAME`` or ``bzr commit FILENAME`` has been changed to
+ include the parent directories if they have altered, and when a
+ directory stops being a directory its children are always included. This
+ fixes a number of causes for ``InconsistentDelta`` errors, and permits
+ faster commit of specific paths. (Robert Collins, #347649)
+
+Documentation
+*************
+
+* New developer documentation for content filtering.
+ (Martin Pool)
+
+API Changes
+***********
+
+* ``bzrlib.shelf_ui`` has had the ``from_args`` convenience methods of its
+ classes changed to manage lock lifetime of the trees they open in a way
+ consistent with reader-exclusive locks. (Robert Collins, #305006)
+
+Testing
+*******
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-2.1.txt b/doc/en/release-notes/bzr-2.1.txt
new file mode 100644
index 0000000..4f0a8f9
--- /dev/null
+++ b/doc/en/release-notes/bzr-2.1.txt
@@ -0,0 +1,1305 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 2.1.5
+#########
+
+:2.1.5: NOT RELEASED YET
+
+Compatibility Breaks
+********************
+
+New Features
+************
+
+Bug Fixes
+*********
+
+* Accessing a packaging branch on Launchpad (eg, ``lp:ubuntu/bzr``) now
+ checks to see if the most recent published source package version for
+ that project is present in the branch tags. This should help developers
+ trust whether the packaging branch is up-to-date and can be used for new
+ changes. The level of verbosity is controlled by the config item
+ ``launchpad.packaging_verbosity``. It can be set to one of
+
+ off
+ disable all checks
+
+
+ minimal
+ only display if the branch is out-of-date
+
+ short
+ also display single-line up-to-date and missing,
+
+
+ all
+ (default) display multi-line content for all states
+
+
+ (John Arbash Meinel, #609187, #812928)
+
+Improvements
+************
+
+Documentation
+*************
+
+API Changes
+***********
+
+Internals
+*********
+
+Testing
+*******
+
+
+bzr 2.1.4
+#########
+
+:2.1.4: 2011-05-16
+
+The fourth release in our 2.1 series addresses some user-inconvenience bugs.
+None are critical, but upgrading is recommended for all users on earlier 2.1
+releases.
+
+
+Compatibility Breaks
+********************
+
+* Launchpad has announced that the ``edge.launchpad.net`` instance is
+ deprecated and may be shut down in the future
+ <http://blog.launchpad.net/general/edge-is-deprecated>. Bazaar has therefore
+ been updated in this release to talk to the main (``launchpad.net``) servers,
+ rather than the ``edge`` ones. (Vincent Ladeuil, #583667)
+
+New Features
+************
+
+None.
+
+Bug Fixes
+*********
+
+* Avoid UnicodeDecodeError in ``bzr add`` with multiple files under a non-ascii
+ path on windows from symlink support addition. (Martin [gz], #686611)
+
+* Skip tests that needs a bzr source tree when there isn't one. This is
+ needed to succesfully run the test suite for installed versions.
+ (Vincent Ladeuil, #644855).
+
+* Skip the tests that requires respecting the chmod bits when running as root.
+ (Vincent Ladeuil, #646133)
+
+* Using bzr with `lp:` URLs behind an HTTP proxy should work.
+ (Robert Collins, #558343)
+
+Improvements
+************
+
+Documentation
+*************
+
+API Changes
+***********
+
+Internals
+*********
+
+Testing
+*******
+
+
+bzr 2.1.3
+#########
+
+:Codename: Do run run
+:2.1.3: 2010-09-17
+
+The third release in our 2.1 series addresses several user-inconvenience bugs
+(and includes the fixes done in 2.0.6). None are critical, but upgrading is
+recommended for all users on earlier 2.1 releases.
+
+Bug Fixes
+*********
+
+* Additional merges after an unrelated branch has been merged with its
+ history no longer crash when deleted files are involved.
+ (Vincent Ladeuil, John Arbash Meinel, #375898)
+
+* ``bzr add SYMLINK/FILE`` now works properly when the symlink points to a
+ previously-unversioned directory within the tree: the directory is
+ marked versioned too.
+ (Martin Pool, #192859)
+
+* ``bzr commit SYMLINK`` now works, rather than trying to commit the
+ target of the symlink.
+ (Martin Pool, John Arbash Meinel, #128562)
+
+* ``bzr upgrade`` now creates the ``backup.bzr`` directory with the same
+ permissions as ``.bzr`` directory on a POSIX OS.
+ (Parth Malwankar, #262450)
+
+* Configuration files in ``${BZR_HOME}`` are now written in an atomic
+ way which should help avoid problems with concurrent writers.
+ (Vincent Ladeuil, #525571)
+
+* Don't traceback trying to unversion children files of an already
+ unversioned directory. (Vincent Ladeuil, #494221)
+
+* Don't traceback when a lockdir's ``held/info`` file is corrupt (e.g.
+ contains only NUL bytes). Instead warn the user, and allow ``bzr
+ break-lock`` to remove it. (Andrew Bennetts, #619872)
+
+* Fix ``AttributeError on parent.children`` when adding a file under a
+ directory that was a symlink in the previous commit.
+ (Martin Pool, #192859)
+
+* Prevent ``CHKMap.apply_delta`` from generating non-canonical CHK maps,
+ which can result in "missing referenced chk root keys" errors when
+ fetching from repositories with affected revisions.
+ (Andrew Bennetts, #522637)
+
+* Raise ValueError instead of a string exception.
+ (John Arbash Meinel, #586926)
+
+* Reduce peak memory by one copy of compressed text.
+ (John Arbash Meinel, #566940)
+
+* Repositories accessed via a smart server now reject being stacked on a
+ repository in an incompatible format, as is the case when accessing them
+ via other methods. This was causing fetches from those repositories via
+ a smart server (e.g. using ``bzr branch``) to receive invalid data.
+ (Andrew Bennetts, #562380)
+
+* Selftest with versions of subunit that support ``stopTestRun`` will no longer
+ error. This error was caused by 2.0 not being updated when upstream
+ python merged the end of run patch, which chose ``stopTestRun`` rather than
+ ``done``. (Robert Collins, #571437)
+
+* Stop ``AttributeError: 'module' object has no attribute 'ElementTree'``
+ being thrown from ``xml_serializer`` on certain cElementTree setups.
+ (Martin [gz], #254278)
+
+* When passing a file to ``UTF8DirReader`` make sure to close the current
+ directory file handle after the chdir fails. Otherwise when passing many
+ filenames into a command line ``bzr status`` we would leak descriptors.
+ (John Arbash Meinel, #583486)
+
+Testing
+*******
+
+* ``build_tree_contents`` can create symlinks.
+ (Martin Pool, John Arbash Meinel)
+
+
+bzr 2.1.2
+#########
+
+:2.1.2: 2010-05-28
+
+This release fixes two critical networking issues with older servers and
+with interrupted system call errors when pushing or pulling. We recommend
+upgrading to anyone running a 2.1.x version of bzr.
+
+Bug Fixes
+*********
+
+* ``bzr clean-tree`` should not delete nested bzrdirs. Required for proper
+ support of bzr-externals and scmproj plugins.
+ (Alexander Belchenko, bug #572098)
+
+* ``bzr switch`` does not die if a ConfigurableFileMerger is used.
+ (Aaron Bentley, #559436)
+
+* Do not register a SIGWINCH signal handler, instead just poll for the
+ terminal width as needed. This avoids the "Interrupted System Call"
+ problems that occur on POSIX with all currently released versions of
+ Python.
+ (Andrew Bennetts, #583941)
+
+* Fixed ``AssertionError`` when accessing smart servers running Bazaar
+ versions before 1.6.
+ (Andrew Bennetts, #528041)
+
+* Reset ``siginterrupt`` flag to False every time we handle a signal
+ installed with ``set_signal_handler(..., restart_syscall=True)`` (from
+ ``bzrlib.osutils``. Reduces the likelihood of "Interrupted System Call"
+ errors compared to registering ``signal.signal`` directly.
+ (Andrew Bennetts)
+
+* Reduce peak memory by one copy of compressed text.
+ (John Arbash Meinel, #566940)
+
+* Support Pyrex 0.9.9, required changing how we handle exceptions in Pyrex.
+ (John Arbash Meinel, #582656)
+
+* When passing a file to ``UTF8DirReader`` make sure to close the current
+ directory file handle after the chdir fails. Otherwise when passing many
+ filenames into a command line ``bzr status`` we would leak descriptors.
+ (John Arbash Meinel, #583486)
+
+Internals
+*********
+
+* ``_remember_remote_is_before`` no longer raises AssertionError when
+ suboptimal network behaviour is noticed; instead it just mutters to the
+ log file (and warns the user if they have set the ``hpss`` debug flag).
+ This was causing unnecessary aborts for performance bugs that are minor
+ at worst.
+ (Andrew Bennetts, #528041)
+
+
+bzr 2.1.1
+#########
+
+:2.1.1: 2010-03-24
+
+This is a small bugfix release. Upgrading is recommended for anyone
+running 2.1.0 or earlier.
+
+Bug Fixes
+*********
+
+* Allow syscalls to automatically restart when ``TextUIFactory``'s
+ SIGWINCH handler is invoked, avoiding ``EINTR`` errors during blocking
+ IO, which are often poorly handled by Python's libraries and parts of
+ bzrlib. (Andrew Bennetts, #496813)
+
+* Avoid ``malloc(0)`` in ``patiencediff``, which is non-portable.
+ (Martin Pool, #331095)
+
+* Fix plugin packaging on Windows. (Ian Clatworthy, #524162)
+
+* Fix stub SFTP test server to call os.getcwdu().
+ (Vincent Ladeuil, #526221, #526353)
+
+* Fixed CHM generation by moving the NEWS section template into
+ a separate file. (Ian Clatworthy, #524184)
+
+* Merge correctly when this_tree is not a WorkingTree. (Aaron Bentley)
+
+* Register SIGWINCH handler only when creating a ``TextUIFactory``; avoids
+ problems importing bzrlib from a non-main thread.
+ (Elliot Murphy, #521989)
+
+* Repositories accessed via a smart server now reject being stacked on a
+ repository in an incompatible format, as is the case when accessing them
+ via other methods. This was causing fetches from those repositories via
+ a smart server (e.g. using ``bzr branch``) to receive invalid data.
+ (Andrew Bennetts, #562380)
+
+* Standardize the error handling when creating a new ``StaticTuple``
+ (problems will raise TypeError). (Matt Nordhoff, #457979)
+
+* Warn if pyrex is too old to compile the new ``SimpleSet`` and
+ ``StaticTuple`` extensions, rather than having the build fail randomly.
+ (John Arbash Meinel, #449776)
+
+Documentation
+*************
+
+* Added a link to the Desktop Guide. (Ian Clatworthy)
+
+* Added What's New in Bazaar 2.1 document. (Ian Clatworthy)
+
+* Drop Google Analytics from the core docs as they caused problems
+ in the CHM files. (Ian Clatworthy, #502010)
+
+API Changes
+***********
+
+* Added ``bzrlib.osutils.set_signal_handler``, a convenience function that
+ can set a signal handler and call ``signal.siginterrupt(signum,
+ False)`` for it, if the platform and Python version supports it.
+ (Andrew Bennetts, #496813)
+
+
+bzr 2.1.0
+#########
+
+:Codename: Strasbourg
+:2.1.0: 2010-02-11
+
+This release marks our second long-term-stable series. The Bazaar team
+has decided that we will continue to make bugfix-only 2.0.x and 2.1.x
+releases, along with 2.2 development releases.
+
+This is a fairly incremental update, focusing on polish and bugfixing.
+There are no changes for supported disk formats. Key updates include
+reduced memory consumption for many operations, a new per-file merge
+hook, ignore patterns can now include '!' to exclude files, globbing
+support for all commands on Windows, and support for addressing home
+directories via ``bzr+ssh://host/~/`` syntax.
+
+Users are encouraged to upgrade from the 2.0 stable series.
+
+Bug Fixes
+*********
+
+* Don't require testtools to use SFTP.
+ (Vincent Ladeuil, #516183)
+
+* Fix "AttributeError in Inter1and2Helper" during fetch.
+ (Martin Pool, #513432)
+
+* ``bzr update`` performs the two merges in a more logical order and will stop
+ when it encounters conflicts.
+ (Gerard Krol, #113809)
+
+* Give a better error message when doing ``bzr bind`` in an already bound
+ branch. (Neil Martinsen-Burrell, #513063)
+
+* Ignore ``KeyError`` from ``remove_index`` during ``_abort_write_group``
+ in a pack repository, which can happen harmlessly if the abort occurs during
+ finishing the write group. Also use ``bzrlib.cleanup`` so that any
+ other errors that occur while aborting the individual packs won't be
+ hidden by secondary failures when removing the corresponding indices.
+ (Andrew Bennetts, #423015)
+
+* Set the mtime of files exported to a directory by ``bzr export`` all to
+ the same value to avoid confusing ``make`` and other date-based build
+ systems. (Robert Collins, #515631)
+
+Improvements
+************
+
+* Fetching into experimental formats will now print a warning. (Jelmer
+ Vernooij)
+
+API Changes
+***********
+
+* ``Repository.deserialise_inventory`` has been renamed to
+ ``Repository._deserialise_inventory`` to indicate it is private.
+ (Jelmer Vernooij)
+
+* ``Repository.get_inventory_xml`` has been renamed to
+ ``Repository._get_inventory_xml`` to indicate it is private.
+ (Jelmer Vernooij)
+
+* ``Repository.serialise_inventory`` has been renamed to
+ ``Repository._serialise_inventory`` to indicate it is private.
+
+* Using the ``bzrlib.chk_map`` module from within multiple threads at the
+ same time was broken due to race conditions with a module level page
+ cache. This shows up as a KeyError in the ``bzrlib.lru_cache`` code with
+ ``bzrlib.chk_map`` in the backtrace, and can be triggered without using
+ the same high level objects such as ``bzrlib.repository.Repository``
+ from different threads. chk_map now uses a thread local cache which may
+ increase memory pressure on processes using threads.
+ (Robert Collins, John Arbash Meinel, #514090)
+
+* The new ``merge_file_content`` should now be ok with tests to avoid
+ regressions.
+ (Vincent Ladeuil, #515597)
+
+Internals
+*********
+
+* Use ``bzrlib.cleanup`` rather than less robust ``try``/``finally``
+ blocks in several places in ``bzrlib.merge``. This avoids masking prior
+ errors when errors like ``ImmortalPendingDeletion`` occur during cleanup
+ in ``do_merge``.
+ (Andrew Bennetts, #517275)
+
+API Changes
+***********
+
+* The ``remove_index`` method of
+ ``bzrlib.repofmt.pack_repo.AggregateIndex`` no longer takes a ``pack``
+ argument. This argument was always ignored.
+ (Andrew Bennetts, #423015)
+
+bzr 2.1.0rc2
+############
+
+:Codename: after the bubbles
+:2.1.0rc2: 2010-01-29
+
+This is a quick-turn-around to update a small issue with our new per-file
+merge hook. We expect no major changes from this to the final 2.1.0.
+
+API Changes
+***********
+
+* The new ``merge_file_content`` hook point has been altered to provide a
+ better API where state for extensions can be stored rather than the
+ too-simple function based approach. This fixes a performance regression
+ where branch configuration would be parsed per-file during merge. As
+ part of this the included news_merger has been refactored into a base
+ helper class ``bzrlib.merge.ConfigurableFileMerger``.
+ (Robert Collins, John Arbash Meinel, #513822)
+
+
+bzr 2.1.0rc1
+############
+
+:Codename: the 'new' stable
+:2.1.0rc1: 2009-01-21
+
+This is the first stable release candidate for Bazaar's 2.1 series. From
+this point onwards, the 2.1 series will be considered stable (as the 2.0
+series) and only bugfixes are expected to be incorporated. The dozen or so
+bugfixes in the 2.0.4 release are also included in this release (along
+with more than 15 more bugfixes). Some of the interesting features are
+support for per-file merge hooks, ``bzr unshelve --preview``, support
+for using ! in ignore files to exclude files from being ignored, a small
+memory leak was squashed, and many ``ObjectNotLocked`` errors were fixed.
+This looks to be a very good start for a new stable series.
+
+
+New Features
+************
+
+* Add bug information to log output when available.
+ (Neil Martinsen-Burrell, Guillermo Gonzalez, #251729)
+
+* Added ``merge_file_content`` hook point to ``Merger``, allowing plugins
+ to register custom merge logic, e.g. to provide smarter merging for
+ particular files.
+
+* Bazaar now includes the ``news_merge`` plugin. It is disabled by
+ default, to enable it add a ``news_merge_files`` option to your
+ configuration. Consult ``bzr help news_merge`` for more information.
+ (Andrew Bennetts)
+
+* ``bzr branch`` now takes a ``--bind`` option. This lets you
+ branch and bind all in one command. (Ian Clatworthy)
+
+* ``bzr switch`` now takes a ``--revision`` option, to allow switching to
+ a specific revision of a branch. (Daniel Watkins, #183559)
+
+* ``bzr unshelve --preview`` can now be used to show how a patch on the
+ shelf would be applied to the working tree.
+ (Guilherme Salgado, #308122)
+
+* ``bzr update`` now takes a ``--revision`` argument. This lets you
+ change the revision of the working tree to any revision in the
+ ancestry of the current or master branch. (Matthieu Moy, Mark Hammond,
+ Martin Pool, #45719)
+
+* ``-Dbytes`` can now be used to display the total number of bytes
+ transferred for the current command. This information is always logged
+ to ``.bzr.log`` for later inspection. (John Arbash Meinel)
+
+* New ignore patterns. Patterns prefixed with '!' are exceptions to
+ ignore patterns and take precedence over regular ignores. Such
+ exceptions are used to specify files that should be versioned which
+ would otherwise be ignored. Patterns prefixed with '!!' act as regular
+ ignore patterns, but have highest precedence, even over the '!'
+ exception patterns. (John Whitley, #428031)
+
+* The ``supress_warnings`` configuration option has been introduced to disable
+ various warnings (it currently only supports the ``format_deprecation``
+ warning). The new option can be set in any of the following locations:
+ ``bazaar.conf``, ``locations.conf`` and/or ``branch.conf``.
+ (Ted Gould, Matthew Fuller, Vincent Ladeuil)
+
+Bug Fixes
+*********
+
+* Always show a message if an OS error occurs while trying to run a
+ user-specified commit message editor.
+ (Martin Pool, #504842)
+
+* ``bzr diff`` will now use the epoch when it is unable to determine
+ the timestamp of a file, if the revision it was introduced in is a
+ ghost. (Jelmer Vernooij, #295611)
+
+* ``bzr switch -b`` can now create branches that are located using directory
+ services such as ``lp:``, even when the branch name doesn't contain a
+ '/'. (Neil Martinsen-Burrell, #495263)
+
+* ``bzr unshelve`` has improved messages about what it is doing.
+ (Neil Martinsen-Burrell, #496917)
+
+* Concurrent autopacking is more resilient to already-renamed pack files.
+ If we find that a file we are about to obsolete is already obsoleted, we
+ do not try to rename it, and we leave the file in ``obsolete_packs``.
+ The code is also fault tolerant if a file goes missing, assuming that
+ another process already removed the file.
+ (John Arbash Meinel, Gareth White, #507557)
+
+* Fix "Too many concurrent requests" in reconcile when network connection
+ fails. (Andrew Bennetts, #503878)
+
+* Fixed a side effect mutation of ``RemoteBzrDirFormat._network_name``
+ that caused some tests to fail when run in a non-default order.
+ Probably no user impact. (Martin Pool, #504102)
+
+* Fixed ``ObjectNotLocked`` error in ``bzr cat -rbranch:../foo FILE``.
+ (Andrew Bennetts, #506274)
+
+* FTP transports support Unicode paths by encoding/decoding them as utf8.
+ (Vincent Ladeuil, #472161)
+
+* Listen to the SIGWINCH signal to update the terminal width.
+ (Vincent Ladeuil, #316357)
+
+* Progress bars are now hidden when ``--quiet`` is given.
+ (Martin Pool, #320035)
+
+* ``SilentUIFactory`` now supports ``make_output_stream`` and discards
+ whatever is written to it. This un-breaks some plugin tests that
+ depended on this behaviour.
+ (Martin Pool, #499757)
+
+* When operations update the working tree, all affected files should end
+ up with the same mtime. (eg. when versioning a generated file, if you
+ update the source and the generated file together, the generated file
+ should appear up-to-date.)
+ (John Arbash Meinel, Martin <gzlist>, #488724)
+
+Improvements
+************
+
+* Added ``add_cleanup`` and ``cleanup_now`` to ``bzrlib.command.Command``.
+ All the builtin commands now use ``add_cleanup`` rather than
+ ``try``/``finally`` blocks where applicable as it is simpler and more
+ robust. (Andrew Bennetts)
+
+* All except a small number of storage formats are now hidden, making
+ the help for numerous commands far more digestible. (Ian Clatworthy)
+
+* Attempts to open a shared repository as a branch (e.g. ``bzr branch
+ path/to/repo``) will now include "location is a repository" as a hint in
+ the error message. (Brian de Alwis, Andrew Bennetts, #440952)
+
+* Push will now inform the user when they are trying to push to a foreign
+ VCS for which roundtripping is not supported, and will suggest them to
+ use dpush. (Jelmer Vernooij)
+
+* The version of bzr being run is now written to the log file.
+ (__monty__, #257170)
+
+* Transport network activity indicator is shown more of the time when
+ Bazaar is doing network IO.
+ (Martin Pool)
+
+Documentation
+*************
+
+* Add documentation on creating merges with more than one parent.
+ (Neil Martinsen-Burrell, #481526)
+
+* Better explain the --uncommitted option of merge.
+ (Neil Martinsen-Burrell, #505088)
+
+* Improve discussion of pending merges in the documentation for
+ ``revert``. (Neil Martinsen-Burrell, #505093)
+
+* Improved help for ``bzr send``.
+ (Martin Pool, Bojan Nikolic)
+
+* There is a System Administrator's Guide in ``doc/en/admin-guide``,
+ including discussions of installation, relevant plugins, security and
+ backup. (Neil Martinsen-Burrell)
+
+* The ``conflicts`` help topic has been renamed to ``conflict-types``.
+ (Ian Clatworthy)
+
+* The User Reference is now presented as a series of topics.
+ Many of the included topics have link and format tweaks applied.
+ (Ian Clatworthy)
+
+API Changes
+***********
+
+* Added ``cachedproperty`` decorator to ``bzrlib.decorators``.
+ (Andrew Bennetts)
+
+* Many test features were renamed from ``FooFeature`` to ``foo_feature``
+ to be consistent with instances being lower case and classes being
+ CamelCase. For the features that were more likely to be used, we added a
+ deprecation thunk, but not all. (John Arbash Meinel)
+
+* Merger classes (such as ``Merge3Merger``) now expect a ``this_branch``
+ parameter in their constructors, and provide ``this_branch`` as an
+ attribute. (Andrew Bennetts)
+
+* The Branch hooks pre_change_branch_tip no longer masks exceptions raised
+ by plugins - the original exceptions are now preserved. (Robert Collins)
+
+* The Transport ``Server.tearDown`` method is now renamed to
+ ``stop_server`` and ``setUp`` to ``start_server`` for consistency with
+ our normal naming pattern, and to avoid confusion with Python's
+ ``TestCase.tearDown``. (Martin Pool)
+
+* ``WorkingTree.update`` implementations must now accept a ``revision``
+ parameter.
+
+Internals
+*********
+
+* Added ``BzrDir.open_branchV3`` smart server request, which can receive
+ a string of details (such as "location is a repository") as part of a
+ ``nobranch`` response. (Andrew Bennetts, #440952)
+
+* New helper osutils.UnicodeOrBytesToBytesWriter which encodes unicode
+ objects but passes str objects straight through. This is used for
+ selftest but may be useful for diff and other operations that generate
+ mixed output. (Robert Collins)
+
+* New exception ``NoRoundtrippingSupport``, for use by foreign branch
+ plugins. (Jelmer Vernooij)
+
+Testing
+*******
+
+* ``bzrlib.tests.permute_for_extension`` is a helper that simplifies
+ running all tests in the current module, once against a pure python
+ implementation, and once against an extension (pyrex/C) implementation.
+ It can be used to dramatically simplify the implementation of
+ ``load_tests``. (John Arbash Meinel)
+
+* ``bzrlib.tests.TestCase`` now subclasses ``testtools.testcase.TestCase``.
+ This permits features in testtools such as getUniqueInteger and
+ getUniqueString to be used. Because of this, testtools version 0.9.2 or
+ newer is now a dependency to run bzr selftest. Running with versions of
+ testtools less than 0.9.2 will cause bzr to error while loading the test
+ suite. (Robert Collins)
+
+* Shell-like tests now support the command "mv" for moving files. The
+ syntax for ``mv file1 file2``, ``mv dir1 dir2`` and ``mv file dir`` is
+ supported. (Neil Martinsen-Burrell)
+
+* The test progress bar no longer distinguishes tests that 'errored' from
+ tests that 'failed' - they're all just failures.
+ (Martin Pool)
+
+
+bzr 2.1.0b4
+###########
+
+:Codename: san francisco airport
+:2.1.0b4: 2009-12-14
+
+The fourth beta release in the 2.1 series brings with it a significant
+number of bugfixes (~20). The test suite is once again (finally) "green"
+on Windows, and should remain that way for future releases. There are a
+few performance related updates (faster upgrade and log), and several UI
+tweaks. There has also been a significant number of tweaks to the runtime
+documentation. 2.1.0b4 include everything from the 2.0.3 release.
+
+
+Compatibility Breaks
+********************
+
+* The BZR_SSH environmental variable may now be set to the path of a secure
+ shell client. If currently set to the value ``ssh`` it will now guess the
+ vendor of the program with that name, to restore the old behaviour that
+ indicated the SSH Corporation client use ``sshcorp`` instead as the magic
+ string. (Martin <gzlist@googlemail.com>, #176292)
+
+New Features
+************
+
+* ``bzr commit`` now has a ``--commit-time`` option.
+ (Alexander Sack, #459276)
+
+* ``-Dhpss`` now increases logging done when run on the bzr server,
+ similarly to how it works on the client. (John Arbash Meinel)
+
+* New option ``bzr unshelve --keep`` applies the changes and leaves them
+ on the shelf. (Martin Pool, Oscar Fuentes, #492091)
+
+* The ``BZR_COLUMNS`` envrionment variable can be set to force bzr to
+ respect a given terminal width. This can be useful when output is
+ redirected or in obscure cases where the default value is not
+ appropriate. Pagers can use it to get a better control of the line
+ lengths.
+ (Vincent Ladeuil)
+
+* The new command ``bzr lp-mirror`` will request that Launchpad update its
+ mirror of a local branch. This command will only function if launchpadlib
+ is installed.
+ (Jonathan Lange)
+
+
+Bug Fixes
+*********
+
+* After renaming a file, the dirstate could accidentally reference
+ ``source\\path`` rather than ``source/path`` on Windows. This might be a
+ source of some dirstate-related failures. (John Arbash Meinel)
+
+* ``bzr commit`` now detects commit messages that looks like file names
+ and issues a warning.
+ (Gioele Barabucci, #73073)
+
+* ``bzr ignore /`` no longer causes an IndexError. (Gorden Tyler, #456036)
+
+* ``bzr log -n0 -rN`` should not return revisions beyond its merged revisions.
+ (#325618, #484109, Marius Kruger)
+
+* ``bzr merge --weave`` and ``--lca`` will now create ``.BASE`` files for
+ files with conflicts (similar to ``--merge3``). The contents of the file
+ is a synthesis of all bases used for the merge.
+ (John Arbash Meinel, #40412)
+
+* ``bzr mv --quiet`` really is quiet now. (Gordon Tyler, #271790)
+
+* ``bzr serve`` is more clear about the risk of supplying --allow-writes.
+ (Robert Collins, #84659)
+
+* ``bzr serve --quiet`` really is quiet now. (Gordon Tyler, #252834)
+
+* Fix bug with redirected URLs over authenticated HTTP.
+ (Glen Mailer, Neil Martinsen-Burrell, Vincent Ladeuil, #395714)
+
+* Interactive merge doesn't leave branch locks behind. (Aaron Bentley)
+
+* Lots of bugfixes for the test suite on Windows. We should once again
+ have a test suite with no failures on Windows. (John Arbash Meinel)
+
+* ``osutils.terminal_width()`` obeys the BZR_COLUMNS environment
+ variable but returns None if the terminal is not a tty (when output is
+ redirected for example). Also fixes its usage under OSes that doesn't
+ provide termios.TIOCGWINSZ. Make sure the corresponding tests runs on
+ windows too.
+ (Joke de Buhr, Vincent Ladeuil, #353370, #62539)
+ (John Arbash Meinel, Vincent Ladeuil, #492561)
+
+* Terminate SSH subprocesses when no references to them remain, fixing
+ subprocess and file descriptor leaks. (Andrew Bennetts, #426662)
+
+* The ``--hardlink`` option of ``bzr branch`` and ``bzr checkout`` now
+ works for 2a format trees. Only files unaffected by content filters
+ will be hardlinked. (Andrew Bennetts, #408193)
+
+* The new glob expansion on Windows would replace all ``\`` characters
+ with ``/`` even if it there wasn't a glob to expand, the arg was quoted,
+ etc. Now only change slashes if there is something being glob expanded.
+ (John Arbash Meinel, #485771)
+
+* Use our faster ``KnownGraph.heads()`` functionality when computing the
+ new rich-root heads. This can cut a conversion time in half (mysql from
+ 13.5h => 6.2h) (John Arbash Meinel, #487632)
+
+* When launching a external diff tool via bzr diff --using, temporary files
+ are no longer created, rather, the path to the file in the working tree is
+ passed to the external diff tool. This allows the file to be edited if the
+ diff tool provides for this. (Gary van der Merwe, #490738)
+
+* The launchpad-open command can now be used from a subdirectory of a
+ branch, not just from the root of the branch.
+ (Neil Martinsen-Burrell, #489102)
+
+
+Improvements
+************
+
+* ``bzr log`` is now faster. (Ian Clatworthy)
+
+* ``bzr update`` provides feedback on which branch it is up to date with.
+ (Neil Martinsen-Burrell)
+
+* ``bzr upgrade`` from pre-2a to 2a can be significantly faster (4x).
+ For details see the xml8 patch and heads() improvements.
+ (John Arbash Meinel)
+
+* ``bzrlib.urlutils.local_path_from_url`` now accepts
+ 'file://localhost/' as well as 'file:///' URLs on POSIX. (Michael
+ Hudson)
+
+* The progress bar now shows only a spinner and per-operation counts,
+ not an overall progress bar. The previous bar was often not correlated
+ with real overall operation progress, either because the operations take
+ nonlinear time, or because at the start of the operation Bazaar couldn't
+ estimate how much work there was to do. (Martin Pool)
+
+Documentation
+*************
+
+* Lots of documentation tweaks for inline help topics and command help
+ information.
+
+API Changes
+***********
+
+* ``bzrlib.textui`` (vestigial module) removed. (Martin Pool)
+
+* The Launchpad plugin now has a function ``login`` which will log in to
+ Launchpad with launchpadlib, and ``load_branch`` which will return the
+ Launchpad Branch object corresponding to a given Bazaar Branch object.
+ (Jonathan Lange)
+
+Internals
+*********
+
+* New test Feature: ``ModuleAvailableFeature``. It is designed to make it
+ easier to handle what tests you want to run based on what modules can be
+ imported. (Rather than lots of custom-implemented features that were
+ basically copy-and-pasted.) (John Arbash Meinel)
+
+* ``osutils.timer_func()`` can be used to get either ``time.time()`` or
+ ``time.clock()`` when you want to do performance timing.
+ ``time.time()`` is limited to 15ms resolution on Windows, but
+ ``time.clock()`` gives CPU and not wall-clock time on other platforms.
+ (John Arbash Meinel)
+
+* Several code paths that were calling ``Transport.get().read()`` have
+ been changed to the equalivent ``Transport.get_bytes()``. The main
+ difference is that the latter will explicitly call ``file.close()``,
+ rather than expecting the garbage collector to handle it. This helps
+ with some race conditions on Windows during the test suite and SFTP
+ tests. (John Arbash Meinel)
+
+Testing
+*******
+
+* TestCaseWithMemoryTransport no longer sets $HOME and $BZR_HOME to
+ unicode strings. (Michael Hudson, #464174)
+
+
+bzr 2.1.0b3
+###########
+
+:Codename: after sprint recovery
+:2.1.0b3: 2009-11-16
+
+This release was pushed up from its normal release cycle due to a
+regression in python 2.4 compatibility in 2.1.0b2. Since this regression
+was caught before 2.1.0b2 was officially announced, the full changelog
+includes both 2.1.0b3 and 2.1.0b2 changes.
+
+Highlights of 2.1.0b3 are: new globbing code for all commands on Windows,
+the test suite now conforms to python's trunk enhanced semantics (skip,
+etc.), and ``bzr info -v`` will now report the correct branch and repo
+formats for Remote objects.
+
+
+New Features
+************
+
+* Users can define a shelve editor to provide shelf functionality at a
+ granularity finer than per-patch-hunk. (Aaron Bentley)
+
+Bug Fixes
+*********
+
+* Fix for shell completion and short options. (Benoît PIERRE)
+
+* Fix ``bzr --profile-imports`` with Python 2.6. (Martin Pool)
+
+* Hooks daughter classes should always call the base constructor.
+ (Alexander Belchenko, Vincent Ladeuil, #389648)
+
+* Improve "Binary files differ" hunk handling. (Aaron Bentley, #436325)
+
+* On Windows, do glob expansion at the command-line level (as is usually
+ done in bash, etc.) This means that *all* commands get glob expansion
+ (bzr status, bzr add, bzr mv, etc). It uses a custom command line
+ parser, which allows us to know if a given section was quoted. It means
+ you can now do ``bzr ignore "*.py"``.
+ (John Arbash Meinel, #425510, #426410, #194450)
+
+* Sanitize commit messages that come in from the '-m' flag. We translate
+ '\r\n' => '\n' and a plain '\r' => '\n'. The storage layer doesn't
+ allow those because XML store silently translate it anyway. (The parser
+ auto-translates \r\n => \n in ways that are hard for us to catch.)
+
+* Show correct branch and repository format descriptions in
+ ``bzr info -v`` on a smart server location. (Andrew Bennetts, #196080)
+
+* The fix for bug #186920 accidentally broke compatibility with python
+ 2.4. (Vincent Ladeuil, #475585)
+
+* Using ``Repository.get_commit_builder().record_iter_changes()`` now
+ correctly sets ``self.inv_sha1`` to a sha1 string and
+ ``self.new_inventory`` to an Inventory instance after calling
+ ``self.finish_inventory()``. (Previously it accidently set both values
+ as a tuple on ``self.inv_sha1``. This was missed because
+ ``repo.add_revision`` ignores the supplied inventory sha1 and recomputes
+ the sha1 from the repo directly. (John Arbash Meinel)
+
+* Shelve command refuse to run if there is no real terminal.
+ (Alexander Belchenko)
+
+* Avoid unnecessarily flushing of trace file; it's now unbuffered at the
+ Python level. (Martin Pool)
+
+Documentation
+*************
+
+* Include Japanese translations for documentation (Inada Naoki)
+
+* New API ``ui_factory.make_output_stream`` to be used for sending bulk
+ (rather than user-interaction) data to stdout. This automatically
+ coordinates with progress bars or other terminal activity, and can be
+ overridden by GUIs.
+ (Martin Pool, 493944)
+
+Internals
+*********
+
+* Some of the core groupcompress functionality now releases the GIL before
+ operation. Similar to how zlib and bz2 operate without the GIL in the
+ core compression and decompression routines. (John Arbash Meinel)
+
+Testing
+*******
+
+* -Dhpssvfs will now trigger on ``RemoteBzrDir._ensure_real``, providing
+ more debugging of VFS access triggers. (Robert Collins)
+
+* KnownFailure is now signalled to ``ExtendedTestResult`` using the same
+ method that Python 2.7 uses - ``addExpectedFailure``. (Robert Collins)
+
+* ``--parallel=fork`` is now compatible with --subunit.
+ (Robert Collins, Vincent Ladeuil, #419776)
+
+* Reporting of failures shows test ids not descriptions and thus shows
+ parameterised tests correctly. (Robert Collins)
+
+* TestNotApplicable is now handled within the TestCase.run method rather
+ than being looked for within ``ExtendedTestResult.addError``. This
+ provides better handling with other ``TestResult`` objects, degrading to
+ sucess rather than error. (Robert Collins)
+
+* The private method ``_testConcluded`` on ``ExtendedTestResult`` has been
+ removed - it was empty and unused. (Robert Collins)
+
+* UnavailableFeature is now handled within the TestCase.run method rather
+ than being looked for within addError. If the Result object does not
+ have an addNotSupported method, addSkip is attempted instead, and
+ failing that addSuccess. (Robert Collins)
+
+* When a TestResult does not have an addSkip method, skipped tests are now
+ reported as successful tests, rather than as errors. This change is
+ to make it possible to get a clean test run with a less capable
+ TestResult. (Robert Collins)
+
+
+
+bzr 2.1.0b2
+###########
+
+:Codename: a load off my mind
+:2.1.0b2: 2009-11-02
+
+This is our second feature-filled release since 2.0, pushing us down the
+path to a 2.1.0. Once again, all bugfixes in 2.0.2 are present in 2.1.0b2.
+
+Key highlights in this release are: improved handling of
+failures-during-cleanup for commit, fixing a long-standing bug with
+``bzr+http`` and shared repositories, all ``lp:`` URLs to be resolved
+behind proxies, and a new StaticTuple datatype, allowing us to reduce
+memory consumption (50%) and garbage collector overhead (40% faster) for
+many operations.
+
+* A new ``--concurrency`` option has been added as well as an associated
+ BZR_CONCURRENCY environment variable to specify the number of
+ processes that can be run concurrently when running ``bzr selftest``. The
+ command-line option overrides the environment variable if both are
+ specified. If none is specified. the number of processes is obtained
+ from the OS as before. (Matt Nordhoff, Vincent Ladeuil)
+
+Bug Fixes
+*********
+
+* ``bzr+http`` servers no longer give spurious jail break errors when
+ serving branches inside a shared repository. (Andrew Bennetts, #348308)
+
+* Errors during commit are handled more robustly so that knock-on errors
+ are less likely to occur, and will not obscure the original error if
+ they do occur. This fixes some causes of ``TooManyConcurrentRequests``
+ and similar errors. (Andrew Bennetts, #429747, #243391)
+
+* Launchpad URLs can now be resolved from behind proxies.
+ (Gordon Tyler, Vincent Ladeuil, #186920)
+
+* Reduce the strictness for StaticTuple, instead add a debug flag
+ ``-Dstatic_tuple`` which will change apis to be strict and raise errors.
+ This way, most users won't see failures, but developers can improve
+ internals. (John Arbash Meinel, #471193)
+
+* TreeTransform.adjust_path updates the limbo paths of descendants of adjusted
+ files. (Aaron Bentley)
+
+* Unicode paths are now handled correctly and consistently by the smart
+ server. (Andrew Bennetts, Michael Hudson, #458762)
+
+Improvements
+************
+
+* When reading index files, we now use a ``StaticTuple`` rather than a
+ plain ``tuple`` object. This generally gives a 20% decrease in peak
+ memory, and can give a performance boost up to 40% on large projects.
+ (John Arbash Meinel)
+
+* Peak memory under certain operations has been reduced significantly.
+ (eg, 'bzr branch launchpad standalone' is cut in half)
+ (John Arbash Meinel)
+
+Documentation
+*************
+
+* Filtered views user documentation upgraded to refer to format 2a
+ instead of pre-2.0 formats. (Ian Clatworthy)
+
+API Changes
+***********
+
+* Remove deprecated ``CLIUIFactory``. (Martin Pool)
+
+* ``UIFactory`` now has new ``show_error``, ``show_message`` and
+ ``show_warning`` methods, which can be hooked by non-text UIs.
+ (Martin Pool)
+
+Internals
+*********
+
+* Added ``bzrlib._simple_set_pyx``. This is a hybrid between a Set and a
+ Dict (it only holds keys, but you can lookup the object located at a
+ given key). It has significantly reduced memory consumption versus the
+ builtin objects (1/2 the size of Set, 1/3rd the size of Dict). This is
+ used as the interning structure for StaticTuple objects.
+ (John Arbash Meinel)
+
+* ``bzrlib._static_tuple_c.StaticTuple`` is now available and used by
+ the btree index parser and the chk map parser. This class functions
+ similarly to ``tuple`` objects. However, it can only point to a limited
+ collection of types. (Currently StaticTuple, str, unicode, None, bool,
+ int, long, float, but not subclasses). This allows us to remove it from
+ the garbage collector (it cannot be in a cycle), it also allows us to
+ intern the objects. In testing, this can reduce peak memory by 20-40%,
+ and significantly improve performance by removing objects from being
+ inspected by the garbage collector. (John Arbash Meinel)
+
+* ``GroupCompressBlock._ensure_content()`` will now release the
+ ``zlib.decompressobj()`` when the first request is for all of the
+ content. (Previously it would only be released if you made a request for
+ part of the content, and then all of it later.) This turns out to be a
+ significant memory savings, as a ``zstream`` carries around approx 260kB
+ of internal state and buffers. (For branching bzr.dev this drops peak
+ memory from 382MB => 345MB.) (John Arbash Meinel)
+
+* When streaming content between ``2a`` format repositories, we now clear
+ caches from earlier versioned files. (So 'revisions' is cleared when we
+ start reading 'inventories', etc.) This can have a significant impact on
+ peak memory for initial copies (~200MB). (John Arbash Meinel)
+
+
+bzr 2.1.0b1
+###########
+
+:Codename: While the cat is away
+:2.1.0b1: 2009-10-14
+
+This is the first development release in the new split "stable" and
+"development" series. As such, the release is a snapshot of bzr.dev
+without creating a release candidate first. This release includes a
+fair amount of internal changes, with deprecated code being removed,
+and several new feature developments. People looking for a stable code
+base with only bugfixes should focus on the 2.0.1 release. All bugfixes
+present in 2.0.1 are present in 2.1.0b1.
+
+Highlights include support for ``bzr+ssh://host/~/homedir`` style URLs,
+finer control over the plugin search path via extended BZR_PLUGIN_PATH
+syntax, visible warnings when extension modules fail to load, and improved
+error handling during unlocking.
+
+
+New Features
+************
+
+* Bazaar can now send mail through Apple OS X Mail.app.
+ (Brian de Alwis)
+
+* ``bzr+ssh`` and ``bzr`` paths can now be relative to home directories
+ specified in the URL. Paths starting with a path segment of ``~`` are
+ relative to the home directory of the user running the server, and paths
+ starting with ``~user`` are relative to the home directory of the named
+ user. For example, for a user "bob" with a home directory of
+ ``/home/bob``, these URLs are all equivalent:
+
+ * ``bzr+ssh://bob@host/~/repo``
+ * ``bzr+ssh://bob@host/~bob/repo``
+ * ``bzr+ssh://bob@host/home/bob/repo``
+
+ If ``bzr serve`` was invoked with a ``--directory`` argument, then no
+ home directories outside that directory will be accessible via this
+ method.
+
+ This is a feature of ``bzr serve``, so pre-2.1 clients will
+ automatically benefit from this feature when ``bzr`` on the server is
+ upgraded. (Andrew Bennetts, #109143)
+
+* Extensions can now be compiled if either Cython or Pyrex is available.
+ Currently Pyrex is preferred, but that may change in the future.
+ (Arkanes)
+
+* Give more control on BZR_PLUGIN_PATH by providing a way to refer to or
+ disable the user, site and core plugin directories.
+ (Vincent Ladeuil, #412930, #316192, #145612)
+
+Bug Fixes
+*********
+
+* Bazaar's native protocol code now correctly handles EINTR, which most
+ noticeably occurs if you break in to the debugger while connected to a
+ bzr+ssh server. You can now can continue from the debugger (by typing
+ 'c') and the process continues. However, note that pressing C-\ in the
+ shell may still kill the SSH process, which is bug 162509, so you must
+ sent a signal to the bzr process specifically, for example by typing
+ ``kill -QUIT PID`` in another shell. (Martin Pool, #341535)
+
+* ``bzr add`` in a tree that has files with ``\r`` or ``\n`` in the
+ filename will issue a warning and skip over those files.
+ (Robert Collins, #3918)
+
+* ``bzr dpush`` now aborts if uncommitted changes (including pending merges)
+ are present in the working tree. The configuration option ``dpush_strict``
+ can be used to set the default for this behavior.
+ (Vincent Ladeuil, #438158)
+
+* ``bzr merge`` and ``bzr remove-tree`` now requires --force if pending
+ merges are present in the working tree.
+ (Vincent Ladeuil, #426344)
+
+* Clearer message when Bazaar runs out of memory, instead of a ``MemoryError``
+ traceback. (Martin Pool, #109115)
+
+* Don't give a warning on Windows when failing to import ``_readdir_pyx``
+ as it is never built. (John Arbash Meinel, #430645)
+
+* Don't restrict the command name used to run the test suite.
+ (Vincent Ladeuil, #419950)
+
+* FTP transports were built differently when the kerberos python module was
+ present leading to obscure failures related to ASCII/BINARY modes.
+ (Vincent Ladeuil, #443041)
+
+* Network streams now decode adjacent records of the same type into a
+ single stream, reducing layering churn. (Robert Collins)
+
+* PreviewTree behaves correctly when get_file_mtime is invoked on an unmodified
+ file. (Aaron Bentley, #251532)
+
+* Registry objects should not use iteritems() when asked to use items().
+ (Vincent Ladeuil, #430510)
+
+* Weave based repositories couldn't be cloned when committers were using
+ domains or user ids embedding '.sig'. Now they can.
+ (Matthew Fuller, Vincent Ladeuil, #430868)
+
+Improvements
+************
+
+* Revision specifiers can now be given in a more DWIM form, without
+ needing explicit prefixes for specifiers like tags or revision id's.
+ See ``bzr help revisionspec`` for full details. (Matthew Fuller)
+
+* Bazaar gives a warning before exiting, and writes into ``.bzr.log``, if
+ compiled extensions can't be loaded. This typically indicates a
+ packaging or installation problem. In this case Bazaar will keep
+ running using pure-Python versions, but this may be substantially
+ slower. The warning can be disabled by setting
+ ``ignore_missing_extensions = True`` in ``bazaar.conf``.
+ See also <https://answers.launchpad.net/bzr/+faq/703>.
+ (Martin Pool, #406113, #430529)
+
+* Secondary errors that occur during Branch.unlock and Repository.unlock
+ no longer obscure the original error. These methods now use a new
+ decorator, ``only_raises``. This fixes many causes of
+ ``TooManyConcurrentRequests`` and similar errors.
+ (Andrew Bennetts, #429747)
+
+Documentation
+*************
+
+* Describe the new shell-like test feature. (Vincent Ladeuil)
+
+* Help on hooks no longer says 'Not deprecated' for hooks that are
+ currently supported. (Ian Clatworthy, #422415)
+
+API Changes
+***********
+
+* ``bzrlib.user_encoding`` has been removed; use
+ ``bzrlib.osutils.get_user_encoding`` instead. (Martin Pool)
+
+* ``bzrlib.tests`` now uses ``stopTestRun`` for its ``TestResult``
+ subclasses - the same as python's unittest module. (Robert Collins)
+
+* ``diff._get_trees_to_diff`` has been renamed to
+ ``diff.get_trees_and_branches_to_diff``. It is now a public API, and it
+ returns the old and new branches. (Gary van der Merwe)
+
+* ``bzrlib.trace.log_error``, ``error`` and ``info`` have been deprecated.
+ (Martin Pool)
+
+* ``MutableTree.has_changes()`` does not require a tree parameter anymore. It
+ now defaults to comparing to the basis tree. It now checks for pending
+ merges too. ``Merger.check_basis`` has been deprecated and replaced by the
+ corresponding has_changes() calls. ``Merge.compare_basis``,
+ ``Merger.file_revisions`` and ``Merger.ensure_revision_trees`` have also
+ been deprecated.
+ (Vincent Ladeuil, #440631)
+
+* ``ProgressTask.note`` is deprecated.
+ (Martin Pool)
+
+Internals
+*********
+
+* Added ``-Drelock`` debug flag. It will ``note`` a message every time a
+ repository or branch object is unlocked then relocked the same way.
+ (Andrew Bennetts)
+
+* ``BTreeLeafParser.extract_key`` has been tweaked slightly to reduce
+ mallocs while parsing the index (approx 3=>1 mallocs per key read).
+ This results in a 10% speedup while reading an index.
+ (John Arbash Meinel)
+
+* The ``bzrlib.lsprof`` module has a new class ``BzrProfiler`` which makes
+ profiling in some situations like callbacks and generators easier.
+ (Robert Collins)
+
+Testing
+*******
+
+* Passing ``--lsprof-tests -v`` to bzr selftest will cause lsprof output to
+ be output for every test. Note that this is very verbose! (Robert Collins)
+
+* Setting ``BZR_TEST_PDB=1`` when running selftest will cause a pdb
+ post_mortem to be triggered when a test failure occurs. (Robert Collins)
+
+* Shell-like tests can now be written. Code in ``bzrlib/tests/script.py`` ,
+ documentation in ``developers/testing.txt`` for details.
+ (Vincent Ladeuil)
+
+* Some tests could end up with the same id, that was dormant for
+ a long time.
+ (Vincent Ladeuil, #442980)
+
+* Stop showing the number of tests due to missing features in the test
+ progress bar. (Martin Pool)
+
+* Test parameterisation now does a shallow copy, not a deep copy of the test
+ to be parameterised. This is not expected to break external use of test
+ parameterisation, and is substantially faster. (Robert Collins)
+
+* Tests that try to open a bzr dir on an arbitrary transport will now
+ fail unless they have explicitly permitted the transport via
+ ``self.permit_url``. The standard test factories such as ``self.get_url``
+ will permit the URLs they provide automatically, so only exceptional
+ tests should need to do this. (Robert Collins)
+
+* The break-in test no longer cares about clean shutdown of the child,
+ instead it is happy if the debugger starts up. (Robert Collins)
+
+* The full test suite is expected to pass when the C extensions are not
+ present. (Vincent Ladeuil, #430749)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
+
diff --git a/doc/en/release-notes/bzr-2.2.txt b/doc/en/release-notes/bzr-2.2.txt
new file mode 100644
index 0000000..6cdbd2f
--- /dev/null
+++ b/doc/en/release-notes/bzr-2.2.txt
@@ -0,0 +1,1340 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 2.2.6
+#########
+
+:2.2.6: NOT RELEASED YET
+
+Compatibility Breaks
+********************
+
+New Features
+************
+
+Bug Fixes
+*********
+
+Improvements
+************
+
+Documentation
+*************
+
+API Changes
+***********
+
+Internals
+*********
+
+Testing
+*******
+
+
+bzr 2.2.5
+#########
+
+:2.2.5: 2011-09-01
+
+This is a bugfix release. One regression introduced in 2.2b1 has been fixed
+for some rare conflict resolutions. Also a warning is now emmitted when
+branching an out-of-date ubuntu packaging branch. Upgrading is recommended
+for all users on earlier 2.2 releases.
+
+Compatibility Breaks
+********************
+
+None.
+
+New Features
+************
+
+None.
+
+Bug Fixes
+*********
+
+* Correctly handle ``bzr log`` and `get_known_graph_ancestry` on a
+ doubly-stacked branch.
+ (James Westby, Martin Pool, #715000)
+
+* Don't crash while merging and encountering obscure path conflicts
+ involving different root-ids. (Vincent Ladeuil, #805809)
+
+Internals
+*********
+
+* Fixed bug in the bundled copy of ConfigObj with quoting of triple quotes
+ in the value string. Fix suggested by ConfigObj's author Michael Foord.
+ (Alexander Belchenko, #710410)
+
+
+bzr 2.2.4
+#########
+
+:2.2.4: 2011-02-04
+
+This is a bugfix release. Only one bug has been fixed, a regression from 2.2.3
+involving only certain operations with launchpad. Upgrading is recommended for
+all users on earlier 2.2 releases.
+
+Bug Fixes
+*********
+
+* Fix communications with the Launchpad web service when using
+ launchpadlib >= 1.5.5. This was a latent bug in bzr's communication
+ with Launchpad's production instance, which only became a problem when
+ the default instance was switched from edge to production in bzr 2.2.3.
+ (Max Bowsher, #707075)
+
+
+bzr 2.2.3
+#########
+
+:2.2.3: 2011-01-20
+
+This is a bugfix release. Upgrading is recommended for all users
+on earlier 2.2 releases.
+
+Compatibility Breaks
+********************
+
+* Launchpad has announced that the ``edge.launchpad.net`` instance is
+ deprecated and may be shut down in the future
+ <http://blog.launchpad.net/general/edge-is-deprecated>. Bazaar has therefore
+ been updated in this release to talk to the main (``launchpad.net``) servers,
+ rather than the ``edge`` ones. (Vincent Ladeuil, #583667)
+
+Bug Fixes
+*********
+
+* Avoid UnicodeDecodeError in ``bzr add`` with multiple files under a non-ascii
+ path on windows from symlink support addition. (Martin [gz], #686611)
+
+* Correctly resolve content (and path) conflicts for files in subdirs.
+ (Vincent Ladeuil, #660935)
+
+* Don't probe for a repository from within ``NotBranchError.__repr__``,
+ because this can cause knock-on errors at awkward times.
+ (Andrew Bennetts, #687653)
+
+* Fix a crash during ``RepositoryPackCollection.pack`` caused by a
+ concurrent repository pack operation. This was particularly affecting
+ ``bzr-svn`` users. (Andrew Bennetts, #701940)
+
+* ``https`` access works again with recent versions of python2.7.
+ (Vincent Ladeuil, #693880)
+
+* RevisionTree.is_executable no longer returns None for directories and
+ symlinks. Instead, it returns False, like other Trees and methods.
+ (Aaron Bentley, #681885)
+
+
+bzr 2.2.2
+#########
+
+:2.2.2: 2010-11-25
+
+This is a bugfix release. None of these bugfixes are critical, but upgrading
+is recommended for all users on earlier 2.2 releases.
+
+Bug Fixes
+*********
+
+* ``bzr resolve --take-other <file>`` will not crash anymore if ``<file>``
+ is involved in a text conflict (but the conflict is still not
+ resolved). (Vincent Ladeuil, #646961)
+
+* Commit in a bound branch or heavyweight checkout now propagates tags
+ (e.g. from a merge) to the master branch (and informs the user if there
+ is a conflict). (Andrew Bennetts, #603395)
+
+* Correctly set the Content-Type header when HTTP POSTing to comply
+ with stricter web frameworks. (Vincent Ladeuil, #665100)
+
+* ``NotBranchError`` no longer allows errors from calling
+ ``bzrdir.open_repository()`` to propagate. This is unhelpful at best,
+ and at worst can trigger infinite loops in callers. (Andrew Bennetts)
+
+* Skip tests that needs a bzr source tree when there isn't one. This is
+ needed to succesfully run the test suite for installed versions.
+ (Vincent Ladeuil, #644855).
+
+* Skip the tests that requires respecting the chmod bits when running as
+ root. Including the one that wasn't present in 2.1.
+ (Vincent Ladeuil, #646133)
+
+* Using bzr with `lp:` URLs behind an HTTP proxy should work.
+ (Robert Collins, #558343)
+
+* Windows installers no longer requires the Microsoft vcredist to be
+ installed.
+ (Martin [gz], Gary van der Merwe, #632465)
+
+* Close leaked socket to SSH subprocesses, which caused dput sftp uploads
+ to hang. (Max Bowsher, #659590)
+
+Testing
+*******
+
+* Add ``tests/ssl_certs/ca.crt`` to the required test files list. Test
+ involving the pycurl https test server fail otherwise when running
+ selftest from an installed version. (Vincent Ladeuil, #651706)
+
+* Fix tests that failed when run under ``LANG=C``.
+ (Andrew Bennetts, #632387)
+
+
+bzr 2.2.1
+#########
+
+:2.2.1: 2010-09-17
+
+This is a bugfix release which also includes bugfixes from 2.0.6 and
+2.1.3. None are critical, but upgrading is recommended for all users on
+earlier 2.2 releases.
+
+Bug Fixes
+*********
+
+* Additional merges after an unrelated branch has been merged with its
+ history no longer crash when deleted files are involved.
+ (Vincent Ladeuil, John Arbash Meinel, #375898)
+
+* ``bzr add SYMLINK/FILE`` now works properly when the symlink points to a
+ previously-unversioned directory within the tree: the directory is
+ marked versioned too.
+ (Martin Pool, #192859)
+
+* ``bzr commit SYMLINK`` now works, rather than trying to commit the
+ target of the symlink.
+ (Martin Pool, John Arbash Meinel, #128562)
+
+* ``bzr upgrade`` now creates the ``backup.bzr`` directory with the same
+ permissions as ``.bzr`` directory on a POSIX OS.
+ (Parth Malwankar, #262450)
+
+* CommitBuilder now uses the committer instead of _config.username to generate
+ the revision-id. (Aaron Bentley, #614404)
+
+* Configuration files in ``${BZR_HOME}`` are now written in an atomic
+ way which should help avoid problems with concurrent writers.
+ (Vincent Ladeuil, #525571)
+
+* Cope with Microsoft FTP server that returns reply '250 Directory
+ created' when mkdir succeeds. (Martin Pool, #224373)
+
+* Don't traceback trying to unversion children files of an already
+ unversioned directory. (Vincent Ladeuil, #494221)
+
+* Don't traceback when a lockdir's ``held/info`` file is corrupt (e.g.
+ contains only NUL bytes). Instead warn the user, and allow ``bzr
+ break-lock`` to remove it. (Andrew Bennetts, #619872)
+
+* Fix ``AttributeError on parent.children`` when adding a file under a
+ directory that was a symlink in the previous commit.
+ (Martin Pool, #192859)
+
+* Fix ``AttributeError: 'NoneType' object has no attribute 'close'`` in
+ ``_close_ssh_proc`` when using ``bzr+ssh://``. This was causing
+ connections to pre-1.6 bzr+ssh servers to fail, and causing warnings on
+ stderr in some other circumstances. (Andrew Bennetts, #633745)
+
+* Only call ``setlocale`` in the bzr startup script on posix systems. This
+ avoids an issue with the newer windows C runtimes used by Python 2.6 and
+ later which can mangle bytestrings printed to the console.
+ (Martin [gz], #631350)
+
+* Prevent ``CHKMap.apply_delta`` from generating non-canonical CHK maps,
+ which can result in "missing referenced chk root keys" errors when
+ fetching from repositories with affected revisions.
+ (Andrew Bennetts, #522637)
+
+* Raise ValueError instead of a string exception.
+ (John Arbash Meinel, #586926)
+
+* Reduce peak memory by one copy of compressed text.
+ (John Arbash Meinel, #566940)
+
+* Repositories accessed via a smart server now reject being stacked on a
+ repository in an incompatible format, as is the case when accessing them
+ via other methods. This was causing fetches from those repositories via
+ a smart server (e.g. using ``bzr branch``) to receive invalid data.
+ (Andrew Bennetts, #562380)
+
+* Selftest with versions of subunit that support ``stopTestRun`` will no longer
+ error. This error was caused by 2.0 not being updated when upstream
+ python merged the end of run patch, which chose ``stopTestRun`` rather than
+ ``done``. (Robert Collins, #571437)
+
+* Stop ``AttributeError: 'module' object has no attribute 'ElementTree'``
+ being thrown from ``xml_serializer`` on certain cElementTree setups.
+ (Martin [gz], #254278)
+
+* Upgrading or fetching from a non-rich-root repository to a rich-root
+ repository (e.g. from pack-0.92 to 2a) no longer fails with
+ ``'Inter1and2Helper' object has no attribute 'source_repo'``. This was
+ a regression from Bazaar 2.1. (Andrew Bennetts, #636930)
+
+* When passing a file to ``UTF8DirReader`` make sure to close the current
+ directory file handle after the chdir fails. Otherwise when passing many
+ filenames into a command line ``bzr status`` we would leak descriptors.
+ (John Arbash Meinel, #583486)
+
+Documentation
+*************
+
+* Fix a lot of references in the docs to the old http://bazaar-vcs.org to
+ the new http://bazaar.canonical.com or http://wiki.bazaar.canonical.com
+ (John Arbash Meinel, #617503)
+
+Internals
+*********
+
+* Remove used and broken code path in ``BranchInitHookParams.__repr__``.
+ (Andrew Bennetts)
+
+Testing
+*******
+
+* ``build_tree_contents`` can create symlinks.
+ (Martin Pool, John Arbash Meinel)
+
+* Tracebacks from a parameterized test are no longer reported against every
+ parameterization of that test. This was done by adding a hack to
+ ``bzrlib.tests.clone_test`` so that it no longer causes
+ testtools.TestCase instances to share a details dict.
+ (Andrew Bennetts, #625574)
+
+bzr 2.2
+#######
+
+:Codename: La Hulpe
+:2.2: 2010-08-06
+
+This release marks the start of another long-term-stable series. From
+here, we will only make bugfix releases on the 2.2 series (2.2.1, etc),
+while 2.3 will become our new development series. The 2.0 and 2.1 series
+will also continue to get bugfixes. (Currently 2.0 is planned to be
+supported for another 6 months.)
+
+This is primarily a bugfix and polish release over the 2.1 series, with
+a large number of bugs fixed (>120), and some performance improvements.
+
+There are some compatibility changes in this release. For users of bzrlib
+as a library, we now request that they call ``bzrlib.initialize`` and use
+the returned context manager appropriately. For commandline users we no
+longer guess user identity for ``bzr commit``, users must specify their
+identity using ``bzr whoami`` (you don't need to specify your identity for
+readonly operations).
+
+Users are encouraged to upgrade from the other stable series.
+
+Compatibility Breaks
+********************
+
+* BzrError subclasses no longer support the name "message" to be used
+ as an argument for __init__ or in _fmt format specification as this
+ breaks in some Python versions. errors.LockError.__init__ argument
+ is now named "msg" instead of earlier "message".
+ (Parth Malwankar, #603461)
+
+* The old ``bzr selftest --benchmark`` option has been removed.
+ <https://launchpad.net/bzr-usertest> is an actively-maintained
+ macrobenchmark suite.
+ (Martin Pool)
+
+Bug Fixes
+*********
+
+* ``bzr ignore PATTERNS`` exits with error if a bad pattern is supplied.
+ ``InvalidPattern`` exception error message now shows faulting
+ regular expression.
+ (Parth Malwankar #300062)
+
+* Configuration files in ``${BZR_HOME}`` are now written in an atomic
+ way which should help avoid problems with concurrent writers.
+ (Vincent Ladeuil, #525571)
+
+* Don't traceback trying to unversion children files of an already
+ unversioned directory. (Vincent Ladeuil, #494221)
+
+* ``HTTP/1.1`` test servers now set a ``Content-Length`` header to comply
+ with pedantic ``HTTP/1.1`` clients. (Vincent Ladeuil, #568421)
+
+* Progress bars prefer to truncate the text message rather than the
+ counters. The spinner is shown between the network transfer indicator
+ and the progress message. Progress bars are correctly cleared off when
+ they finish. (Martin Pool, #611127)
+
+* Recursive binding for checkouts is now detected by bzr. A clear error
+ message is shown to the user. (Parth Malwankar, #405192)
+
+Improvements
+************
+
+* Add ``bzrlib.merge.MergeIntoMerger``, which can merge part or all of a
+ tree, and works with unrelated branches. (Andrew Bennetts)
+
+* Add py2exe windows target ``bzrw.exe``. This allow for starting a Bazaar
+ GUI with out have a console open in the background.
+ (Gary van der Merwe, #433781)
+
+Documentation
+*************
+
+* ``bzr help patterns`` now explains case insensitive patterns and
+ points to Python regular expression documentation.
+ (Parth Malwankar, #594386)
+
+API Changes
+***********
+
+* Delete ``ProgressTask.note``, which was deprecated in 2.1.
+
+Testing
+*******
+
+* Unit test added to ensure that "message" is not uses as a format variable
+ name in BzrError subclasses as this conflicts with some Python versions.
+ (Parth Malwankar, #603461)
+
+bzr 2.2b4
+#########
+
+:Codename: Monkey Magic
+:2.2b4: 2010-07-10
+
+
+This fourth and final beta in the 2.2 series now stabilizes the internal
+APIs. Plugin authors are recommended to ensure their releases are
+compatible, so that 2.2rc1 can be a true release candidate, containing
+stable and compatible plugin versions.
+
+For users of bzrlib as a library, one of the primary changes is to request
+that they call ``bzrlib.initialize`` and use the returned context manager
+appropriately.
+
+Better interaction with ``bzr-loom`` to make sure branching from a loom
+even over a smart server still yields a local loom. Not to mention lots of
+bugfixes over 2.2b3.
+
+Compatibility Breaks
+********************
+
+* bzrlib library users now need to call ``__enter__`` and ``__exit__`` on
+ the result of ``bzrlib.initialize``. This change was made when fixing
+ the bad habit recent bzr versions have had of leaving progress bars
+ behind on the screen. That required calling another function before
+ exiting the program, and it made sense to provide a full context
+ manager at the same time. (Robert Collins)
+
+* The ``bzr`` front end now requires a ``bzrlib.ui.ui_factory`` which is a
+ context manager in the Python 2.5 and above sense. The bzrlib base class
+ is such a manager, but third party UI factories which do not derive from
+ ``bzrlib.ui.UIFactory`` will be incompatible with the command line front
+ end.
+
+* URLs like ``foo:bar/baz`` are now always parsed as a URL with scheme "foo"
+ and path "bar/baz", even if bzr does not recognize "foo" as a known URL
+ scheme. Previously these URLs would be treated as local paths.
+ (Gordon Tyler)
+
+
+New Features
+************
+
+* Support ``--directory`` option for a number of additional commands:
+ conflicts, merge-directive, missing, resolve, shelve, switch,
+ unshelve, whoami. (Martin von Gagern, #527878)
+
+Bug Fixes
+*********
+
+* ``bzr branch`` to a new repository with a default stacking policy no
+ longer transfers the full history unnecessarily.
+ (Andrew Bennetts, #597942)
+
+* ``bzr init`` does not recursively scan directory contents anymore
+ leading to faster init for directories with existing content.
+ (Martin [gz], Parth Malwankar, #501307)
+
+* ``bzr log --exclude-common-ancestry`` is now taken into account for
+ linear ancetries. (Vincent Ladeuil, #575631)
+
+* ``bzr log -r branch:REMOTE`` can now properly log the remote branch,
+ rather than trying to fetch the data locally and failing because of a
+ readonly error. (Martin von Gagern, #149270)
+
+* ``bzr pull`` now works when a lp: URL is explicitly defined as the parent
+ or pull location in locations.conf or branch.conf.
+ (Gordon Tyler, #534787)
+
+* ``bzr reconfigure --unstacked`` now works with branches accessed via a
+ smart server. (Andrew Bennetts, #551525)
+
+* ``BzrDir.find_branches`` should ignore branches with missing repositories.
+ (Marius Kruger, Robert Collins)
+
+* ``BzrDir.find_bzrdirs`` should ignore dirs that raises PermissionDenied.
+ (Marius Kruger, Robert Collins)
+
+* Ensure that wrong path specifications in ``BZR_PLUGINS_AT`` display
+ proper error messages. (Vincent Ladeuil, #591215)
+
+* Explicitly removing ``--profile-imports`` option from parsed command-line
+ arguments on Windows, because bzr script does the same.
+ (Alexander Belchenko, #588277)
+
+* Fetching was slightly confused about the best code to use and was
+ using a new code path for all branches, resulting in more lookups than
+ necessary on old branches. (Robert Collins, #593515)
+
+* Final fix for 'no help for command' issue. We now show a clean message
+ when a command has no help, document how to set help more clearly, and
+ test that all commands available to the test suite have help.
+ (Robert Collins, #177500)
+
+* Invalid patterns supplied to ``Globster`` or ``lazy_regex`` now raise
+ ``InvalidPattern`` exception showing clear error message to the user.
+ (Parth Malwankar #300062)
+
+* Progress output is cleaned up when exiting. (Aaron Bentley)
+
+* Raise ValueError instead of a string exception.
+ (John Arbash Meinel, #586926)
+
+* Relative imports in plugins are now handled correctly when using
+ BZR_PLUGINS_AT. (Vincent Ladeuil, #588959)
+
+* ``ScriptRunner`` now strips off leading indentation from test scripts,
+ which previously caused "SyntaxError: No command for line".
+ (Martin Pool)
+
+* Show unicode filenames in diff headers using terminal encoding.
+ (Alexander Belchenko, Bug #382699)
+ NOTE for Windows users: If user need to save diff to file then user need to
+ change encoding of the terminal to ANSI encoding with command ``chcp XXX``
+ (e.g. ``chcp 1251`` for Russian Windows).
+
+* URL displayed for use with ``break-lock`` when smart server sees lock
+ contention are now valid. Default timeout for lock contention retry is
+ now 30 seconds instead of 300 seconds.
+ (Parth Malwankar, #250451)
+
+* ``walkdirs`` now raises a useful message when the filenames are not using
+ the filesystem encoding. (Eric Moritz, #488519)
+
+* Enable debugging of bzr on windows with pdb and other tools. This was
+ broken because we call GetCommandLineW on windows. The fix adjusts the
+ command line we get to be the same length as sys.argv.
+ (Jason Spashett, Alexander Belchenko, #587868)
+
+Improvements
+************
+
+* Bazaar now reads data from SSH connections more efficiently on platforms
+ that provide the ``socketpair`` function, and when using paramiko.
+ (Andrew Bennetts, #590637)
+
+* ``Branch.copy_content_into`` is now a convenience method dispatching to
+ a ``InterBranch`` multi-method. This permits ``bzr-loom`` and other
+ plugins to intercept this even when a ``RemoteBranch`` proxy is in use.
+ (Robert Collins, #201613)
+
+* ``Branch`` formats can now be loaded lazily by registering a
+ ``MetaDirBranchFormatFactory`` rather than an actual format. This will
+ cause the named format class to be loaded only when an enumeration of
+ formats is needed or when the format string for the object is
+ encountered. (Robert Collins, Jelmer Vernooij)
+
+* The encoding that bzr uses to output things other than file content can
+ now be overridden via the output_encoding configuration option.
+ (Martin Pool, #340394)
+
+* Use lazy imports in ``bzrlib/merge.py`` so that plugins like ``news_merge``
+ do not cause modules to be loaded unnecessarily just because the plugin
+ registers a merge hook. This improves ``bzr rocks`` time by about 25%
+ in a default installation (with just the core plugins).
+ (Andrew Bennetts)
+
+Documentation
+*************
+
+* Added ``regression`` tag to our tags list. (Robert Collins)
+
+* Improved our release checklist to have a bit less churn and leave things
+ ready-to-go for the next action (including other people doing
+ development). (Robert Collins)
+
+* Remove obsolete discussion of PQM in documentation about how to
+ contribute to Bazaar. (Martin Pool, #588444)
+
+API Changes
+***********
+
+* ``bzrlib.branch.InterBranch._get_branch_formats_to_test`` now returns
+ an iterable of format pairs, rather than just a single pair, permitting
+ InterBranch objects that work with multiple permutations to be
+ comprehensively tested. (Robert Collins)
+
+* ``bzrlib.lsprof.profile`` will no longer silently generate bad threaded
+ profiles when concurrent profile requests are made. Instead the profile
+ requests will be serialised. Reentrant requests will now deadlock.
+ (Robert Collins)
+
+* ``bzrlib.knit.KnitSequenceMatcher``, which has been deprecated since
+ 2007, has been deleted. Use ``PatienceSequenceMatcher`` from
+ ``bzrlib.patiencediff`` instead. (Andrew Bennetts)
+
+* ``bzrlib.re_compile_checked`` is now deprecated. Caller should handle
+ ``bzrlib.errors.InvalidPattern`` exception thrown by ``re.match`` in
+ case the default error message not suitable for the use case.
+ (Parth Malwankar)
+
+* ``bzrlib.tests.blackbox.ExternalBase`` is deprecated. It provided only
+ one method ``check_output``, and we now recommend checking command
+ output using ``run_script``. (Martin Pool)
+
+* ``bzrlib.transport.ssh.SSHVendor.connect_ssh`` now returns an object
+ that implements the interface of ``bzrlib.transport.ssh.SSHConnection``.
+ Third-party implementations of ``SSHVendor`` may need to be updated
+ accordingly. Similarly, any code using ``SSHConnection`` directly will
+ need to be updated. (Andrew Bennetts)
+
+* The constructor of ``bzrilb.smart.medium.SmartSSHClientMedium`` has
+ changed to take an ``SSHParams`` instance (replacing many individual
+ values). (Andrew Bennetts)
+
+Internals
+*********
+
+* ``bzrlib.osutils.get_terminal_encoding`` will now only mutter its
+ selection when explicitly requested; this avoids many duplicate calls
+ being logged when helpers, wrappers and older code that manually calls
+ it are executed it is now logged deliberately by the ui setup code.
+ (Robert Collins)
+
+* Improved ``bzrlib.urlutils`` to handle lp:foo/bar URLs. (Gordon Tyler)
+
+* ``bzrlib._c_static_tuple.StaticTuple`` now implements ``__sizeof__``, so
+ that ``sys.getsizeof`` and other memory analysis tools will report more
+ accurate results. (Andrew Bennetts)
+
+* The symbol_versioning module can now cleanup after itself -
+ ``suppress_deprecation_warnings`` now returns a cleanup function.
+ (Robert Collins)
+
+Testing
+*******
+
+* Add ``bzrlib.tests.fixtures`` to hold code for setting up objects
+ to test. (Martin Pool)
+
+* ``test_import_tariff`` now respects BZR_PLUGINS_AT and BZR_PLUGINS_DISABLE.
+ (Vincent Ladeuil, #595587)
+
+
+bzr 2.2b3
+#########
+
+:2.2b3: 2010-05-28
+
+This third beta in the 2.2 series brings with it all the goodness of 2.1.2
+and 2.0.6 (though it preceeds 2.0.6 slightly). Of particular note for
+users are compatibility fixes with bzr 1.5 and below servers, a hopeful
+end to the EINTR errors caused by SIGWINCH interactions, a shiny new
+bash completion script and bzr will no longer guess at identity details -
+it was too unreliable in reality. Use ``bzr whoami`` on every new install.
+For developers we have some API changes which may impact plugins as well
+as a bunch of our regular improvements to internal clarity and test
+support.
+
+Compatibility Breaks
+********************
+
+* An API break has been made to the lock_write method of ``Branch`` and
+ ``Repository`` objects; they now return ``branch.BranchWriteLockResult``
+ and ``repository.RepositoryWriteLockResult`` objects. This makes
+ changing the API in future easier and permits some cleaner calling code.
+ The lock_read method has also changed from having no defined return
+ value to returning ``LogicalLockResult`` objects.
+ (Robert Collins)
+
+* ``bzr`` does not try to guess the username as ``username@hostname``
+ and requires it to be explictly set. This can be set using ``bzr
+ whoami``. (Parth Malwankar, #549310)
+
+* ``bzrlib.commands.Command`` will now raise ValueError during
+ construction if there is no __doc__ set. (Note, this will be reverted in
+ 2.2b4) (Robert Collins)
+
+* The source tree no longer contains a contrib/zsh/_bzr completion
+ script. The new file contrib/zsh/README suggests alternatives.
+ (Martin von Gagern, #560030)
+
+New Features
+************
+
+* ``bzr commit`` accepts ``-p`` (for "patch") as a shorter name for
+ ``--show-diff``.
+ (Parth Malwankar, #571467)
+
+* ``bzr ignore`` now supports a ``--default-rules`` option that displays
+ the default ignore rules used by bzr. The flag ``--old-default-rules``
+ is no longer supported by ``ignore``.
+ (Parth Malwankar, #538703)
+
+* ``bzr pack`` now supports a ``--clean-obsolete-packs`` option that
+ can save disk space by deleting obsolete pack files created during the
+ pack operation.
+ (Parth Malwankar, #304320)
+
+* New command line option ``--authors`` to ``bzr log`` allows users to
+ select which of the apparent authors and committer should be
+ included in the log. Defaults depend on format. (Martin von Gagern, #513322)
+
+* Support ``--directory`` option for a number of additional commands:
+ added, annotate, bind, cat, cat-revision, clean-tree, deleted,
+ export, ignore, ignored, lookup-revision, ls, modified, nick,
+ re-sign, unbind, unknowns.
+ (Martin von Gagern, #527878)
+
+* The bash_completion plugin from the bzr-bash-completion project has
+ been merged into the tree. It provides a bash-completion command and
+ replaces the outdated ``contrib/bash/bzr`` script with a version
+ using the plugin. (Martin von Gagern, #560030)
+
+* A new transport based on GIO (the Gnome I/O library) provides access to
+ Samba shares, WebDAV using gio+smb and gio+dav. It is also possible to
+ use gio for some already existing transport methods as gio+file,
+ gio+sftp, gio+ftp.
+ (Mattias Eriksson)
+
+Bug Fixes
+*********
+
+* Alias information shown by ``bzr help`` is now accurate. This
+ was showing an internal object name for some plugin aliases.
+ (Parth Malwankar, #584650)
+
+* ``.bazaar``, ``.bazaar/bazaar.conf`` and ``.bzr.log`` inherit user and
+ group ownership from the containing directory. This allow bzr to work
+ better with sudo.
+ (Martin <gzlist@googlemail.com>, Parth Malwankar, #376388)
+
+* ``bzr clean-tree`` should not delete nested bzrdirs. Required for proper
+ support of bzr-externals and scmproj plugins.
+ (Alexander Belchenko, bug #572098)
+
+* ``bzr ignore`` will no longer add duplicate patterns to .bzrignore.
+ (Gordon Tyler, #572092)
+
+* ``bzr log --exclude-common-ancestry -r X..Y`` displays the revisions that
+ are part of Y ancestry but not part of X ancestry (aka the graph
+ difference).
+ (Vincent Ladeuil, #320119)
+
+* ``bzr lp-propose`` which was switched to use production Launchpad API
+ servers a few commits ago has been reverted to use edge: there is a
+ problem with using production which isn't trivially obvious, so we've
+ filed a bug to track it, and until thats fixed will be using edge.
+ (Robert Collins, #583667)
+
+* ``bzr rm`` should not refuse to delete directories which contained a file
+ which has been moved elsewhere in the tree after the previous commit.
+ (Marius Kruger, Daniel Watkins, #129880)
+
+* ``bzr selftest --parallel=fork`` wait for its children avoiding zombies.
+ (Vincent Ladeuil, #566670)
+
+* ``bzr selftest`` should not use ui.note() since it's not unicode safe.
+ (Vincent Ladeuil, #563997)
+
+* CommitBuilder refuses to create revisions whose trees have no root.
+ (Aaron Bentley)
+
+* Do not register a SIGWINCH signal handler, instead just poll for the
+ terminal width as needed. This avoids the "Interrupted System Call"
+ problems that occur on POSIX with all currently released versions of
+ Python.
+ (Andrew Bennetts, #583941)
+
+* Don't mention --no-strict when we just issue the warning about unclean trees.
+ (Vincent Ladeuil, #401599)
+
+* Fixed ``AssertionError`` when accessing smart servers running Bazaar
+ versions before 1.6.
+ (Andrew Bennetts, #528041)
+
+* Improved progress bar for fetch (2a format only). Bazaar now shows an
+ estimate of the number of records to be fetched vs actually fetched.
+ (Parth Malwankar, #374740, #538868)
+
+* Reduce peak memory by one copy of compressed text.
+ (John Arbash Meinel, #566940)
+
+* ``RemoteBranch.lock_write`` raises ``ReadOnlyError`` if called during a
+ read lock, rather than causing an ``AttributeError``.
+ (Andrew Bennetts, Danilo Segan, #582781)
+
+* Selftest was failing with testtools 0.9.3, which caused an
+ AssertionError raised from a cleanUp to be reported as a Failure, not an
+ Error, breaking on of our test hygiene tests.
+ (Robert Collins, Vincent Ladeuil).
+
+* ``set_user_option`` with a dict on remote branches no longer fails with
+ an AttributeError. There is a new ``Branch.set_config_option_dict`` RPC
+ to support this efficiently.
+ (Andrew Bennetts, #430382)
+
+* Show the filenames when a file rename fails so that the error will be
+ more comprehensible.
+ (Martin Pool, #491763)
+
+* Support Pyrex 0.9.9, required changing how we handle exceptions in Pyrex.
+ (John Arbash Meinel, #582656)
+
+* Unicode characters in aliases are now handled correctly and do not cause
+ UnicodeEncodeError exception. (Parth Malwankar, #529930)
+
+* Unicode commit messages that are the same as a file name no longer cause
+ UnicodeEncodeError. ``ui.text.show_warning`` now handles unicode
+ messages.
+ (Parth Malwankar, #563646)
+
+* When passing a file to ``UTF8DirReader`` make sure to close the current
+ directory file handle after the chdir fails. Otherwise when passing many
+ filenames into a command line ``bzr status`` we would leak descriptors.
+ (John Arbash Meinel, #583486)
+
+Improvements
+************
+
+* ``append_revisions_only`` will now be interpreted as a boolean and a
+ warning emitted if illegal values are used. Note that for projects
+ that needs to maintain compatibility with previsous bzr versions,
+ only 'True' and 'False' strings must be used (previous versions of
+ bzr will interpret all strings differing from 'True'
+ (case-sensitive) as false.
+ (Brian de Alwis, Vincent Ladeuil)
+
+* ``bzr ls`` now supports short options for existing long options.
+ ``-k/--kind``, ``-i/--ignored``, ``-u/--unknown`` and ``-0/--null``.
+ (Parth Malwankar, #181124)
+
+* ``Config.get_user_option_as_bool`` will now warn if a value cannot
+ be interpreted as a boolean.
+ (Vincent Ladeuil)
+
+* The all-in-one Windows installer will now be built with docstrings stripped
+ from the library zip, reducing the size and slightly improving cold startup
+ time. Bundled plugins are unchanged for the moment, but if adding other new
+ plugins to an all-in-one installation, ensure they are compiled and
+ installed with -O1 or help may not work. (Martin [gz])
+
+API Changes
+***********
+
+* Added ``bzrlib.merge.PerFileMerger``, a more convenient way to write
+ some kinds of ``merge_file_content`` hook functions.
+ (Andrew Bennetts)
+
+* `BzrDir`, `Branch`, `Repository` and `WorkingTree` now all support `user_url`,
+ `user_transport`, `control_url` and `control_transport` members pointing
+ respectively to the directory containing the ``.bzr`` control directory,
+ and to the directory within ``.bzr`` used for the particular component.
+ All of them inherit from `ControlComponent` which provides default
+ implementations.
+ (Martin Pool)
+
+* Lock methods on ``Tree``, ``Branch`` and ``Repository`` are now
+ expected to return an object which can be used to unlock them. This reduces
+ duplicate code when using cleanups. The previous 'tokens's returned by
+ ``Branch.lock_write`` and ``Repository.lock_write`` are now attributes
+ on the result of the lock_write. ``repository.RepositoryWriteLockResult``
+ and ``branch.BranchWriteLockResult`` document this. (Robert Collins)
+
+* ``Repository.refresh_data`` may now be called in a write group on
+ pack-based repositories. Older repositories will still raise an error
+ in this case. Subclasses of ``Repository`` can still override
+ ``Repository._refresh_data``, but are now responsible for raising
+ ``bzrlib.repository.IsInWriteGroupError`` if they do not support
+ ``refresh_data`` during a write group.
+ (Andrew Bennetts, #574236)
+
+Internals
+*********
+
+* ``chk_map._bytes_to_text_key`` is now an optimized function to extract
+ the (file-id, revision-id) key from a CHKInventory entry. This can
+ potentially shave 5-10% time off during a large fetch. Related to bug
+ #562666. (John Arbash Meinel)
+
+* ``log._get_info_for_log_files`` now takes an add_cleanup callable.
+ (Robert Collins)
+
+* ``_remember_remote_is_before`` no longer raises AssertionError when
+ suboptimal network behaviour is noticed; instead it just mutters to the
+ log file (and warns the user if they have set the ``hpss`` debug flag).
+ This was causing unnecessary aborts for performance bugs that are minor
+ at worst.
+ (Andrew Bennetts, #528041)
+
+* Permit bzr to run under ``python -OO`` which reduces the size of bytecode
+ files loaded from disk. To ensure docstrings needed for help are never
+ stripped, the prefix ``__doc__ =`` should now be used.
+ (Martin <gzlist@googlemail.com>)
+
+* No longer require zlib headers to build extensions, and remove the need
+ for seperate copy of zlib library on windows.
+ (John Arbash Meinel, Martin <gzlist@googlemail.com>, #566923)
+
+Testing
+*******
+
+* Added ``bzrlib.tests.matchers`` as a place to put matchers, along with
+ our first in-tree matcher. See the module docstring for details.
+ (Robert Collins)
+
+* ``bzr selftest --parallel=subprocess`` now works correctly on win32.
+ (Gordon Tyler, #551332)
+
+* Workaround ``Crypto.Random`` check leading to spurious test
+ failures on Lucid, FreeBSD and gentoo.
+ (Vincent Ladeuil, #528436)
+
+* New class ``ExecutableFeature`` for checking the availability of
+ executables on the ``PATH``. Migrated from bash_completion plugin.
+ (Martin von Gagern)
+
+
+bzr 2.2b2
+#########
+
+:2.2b2: 2010-04-16
+
+This is a somewhat early second beta of the 2.2 series, to fix a python2.4
+incompatibility in the 2.2b1 release. It also includes a swag of
+performance, usability and correctness improvements: test feedback on all
+of these would be welcome.
+
+
+New Features
+************
+
+* ``bzr diff`` now supports a --format option, which can be used to
+ select alternative diff formats. (Jelmer Vernooij, #555994)
+
+Bug Fixes
+*********
+
+* ``bzr dpush``, ``bzr push`` and ``bzr send`` will now issue a warning
+ instead of failing when dirty trees are involved. The corresponding
+ ``dpush_strict``, ``push_strict`` and ``send_strict`` should be set to
+ True explicitly to get the previous behaviour.
+ (Vincent Ladeuil, #519319)
+
+* ``bzr export`` to tar file does not fail if any parent directory
+ contains unicode characters. This works around upstream Python bug
+ http://bugs.python.org/issue8396 .
+ (Parth Malwankar, #413406)
+
+* ``bzr switch`` does not die if a ConfigurableFileMerger is used.
+ (Aaron Bentley, #559436)
+
+* ``bzr update`` when a pending merge in the working tree has been merged
+ into the master branch will no longer claim that old commits have become
+ pending merges. (Robert Collins, #562079)
+
+* ``bzrlib.mutabletree.MutableTree.commit`` will now support a passed in
+ config as in previous versions of bzrlib. (Robert Collins)
+
+* Fix glitch in the warning about unclean trees display.
+ (Vincent Ladeuil, #562665)
+
+* Fixed Python2.4 incompatibilities in the bzr2.2b1 source tarball.
+ (Martin Pool)
+
+* Help messages generated by ``RegistryOption.from_kwargs`` list the
+ switches in alphabetical order, rather than in an undefined order.
+ (Martin von Gagern, #559409)
+
+* Make sure the ``ExecutablePath`` and ``InterpreterPath`` are set in
+ Apport crash reports, to avoid "This problem report applies to a program
+ which is not installed any more" error.
+ (Martin Pool, James Westby, #528114)
+
+* Reset ``siginterrupt`` flag to False every time we handle a signal
+ installed with ``set_signal_handler(..., restart_syscall=True)`` (from
+ ``bzrlib.osutils``. Reduces the likelihood of "Interrupted System Call"
+ errors compared to registering ``signal.signal`` directly.
+ (Andrew Bennetts)
+
+* When invoked with a range revision, ``bzr log`` doesn't show revisions
+ that are not part of the Y revisions ancestry anymore when invoked with
+ -rX..Y.
+ (Vincent Ladeuil, #474807)
+
+* Properly handle ``param_name`` attribute for ``ListOption``.
+ (Martin von Gagern, #387117)
+
+Improvements
+************
+
+* ``bzr commit`` will prompt before using a commit message that was
+ generated by a template and not edited by the user.
+ (Robert Collins, #530265)
+
+* ``bzr diff`` read-locks the trees and branches only once, saving about
+ 10-20ms on ``bzr diff`` in a bzr.dev tree.
+ (Andrew Bennetts)
+
+* ``bzr missing`` read-locks the branches only once.
+ (Andrew Bennetts)
+
+* ``bzr pull`` locks the branches and tree only once.
+ (Andrew Bennetts)
+
+* Index lookups in pack repositories search recently hit pack files first.
+ In repositories with many pack files this can greatly reduce the
+ number of files accessed, the number of bytes read, and the number of
+ read calls. An incremental pull via plain HTTP takes half the time and
+ bytes for a moderately large repository. (Andrew Bennetts)
+
+* Index lookups only re-order the indexes when the hit files aren't
+ already first. Reduces the cost of reordering
+ (John Arbash Meinel, #562429)
+
+* Less code is loaded at startup. (Cold-cache start time is about 10-20%
+ less.)
+ (Martin Pool, #553017)
+
+API Changes
+***********
+
+* ``bzrlib.diff.get_trees_and_branches_to_diff`` is deprecated. Use
+ ``get_trees_and_branches_to_diff_locked`` instead.
+ (Andrew Bennetts)
+
+* ``TreeTransform.commit`` supports the full set of commit parameters, and
+ auto-determines branch nick if not supplied. (Aaron Bentley)
+
+Internals
+*********
+
+* ``bzrlib.commands.Command.run_direct`` is no longer needed - the pre
+ 2.1 method of calling run() to perform testing or direct use via the API
+ is now possible again. As part of this, the _operation attribute on
+ Command is now transient and only exists for the duration of ``run()``.
+ (Robert Collins)
+
+bzr 2.2b1
+#########
+
+:2.2b1: 2010-04-01
+
+This is the first beta of the 2.2 series, leading up to a 2.2.0
+release in July or August. Beta releases are suitable for everyday use
+but may cause some incompatibilities with plugins. Some plugins may need
+small updates to work with 2.2b1.
+
+2.2b1 includes some changes to make merge conflicts easier to understand
+and resolve. It also removes some old unnecessary code, and loads
+somewhat less code at startup. It starts adding a common infrastructure
+for dealing with colocated named branches, which can be implemented in
+various ways in either bzr native or foreign formats. On Ubuntu and
+other platforms with the apport bug-reporting library, there's an easier
+path to report problems with bzr. We plan to continue with these themes
+through the 2.2 series.
+
+Over thirty bugs have been fixed, including in the log command, exporting
+to tarballs, restarting interrupted system calls, portability of compiled
+extensions, making backups during upgrade, and locking on FTP.
+
+Compatibility Breaks
+********************
+
+* BTreeGraphIndex can now take an offset to indicate that the data starts
+ somewhere other than then beginning of the file. (John Arbash Meinel)
+
+* Deleted very old hidden commands ``versionedfile-list``,
+ ``weave-plan-merge``, ``weave-merge-text``.
+ (Martin Pool)
+
+* ``Repository.get_inventory_sha1()`` and ``Repository.get_revision_xml()``
+ have been removed. (Jelmer Vernooij)
+
+* ``Repository.get_revision_inventory()`` has been removed in favor of
+ ``Repository.get_inventory()``. (Jelmer Vernooij)
+
+* All test servers have been moved out of the bzrlib.transport hierarchy to
+ bzrlib.tests.test_server *except* for MemoryServer, ChrootServer and
+ PathFilteringServer. ``bzrlib`` users may encounter test failures that can
+ be fixed by updating the related imports from ``bzrlib.transport.xxx`` to
+ ``bzrlib.tests.test_server``.
+ (Vincent Ladeuil)
+
+* ``BranchReferenceFormat.initialize()`` now takes an optional name argument
+ as its second parameter, for consistency with the initialize() method of
+ other formats. (Jelmer Vernooij)
+
+New Features
+************
+
+* Added ``bzr remove-branch`` command that can remove a local or remote
+ branch. (Jelmer Vernooij, #276295)
+
+* ``bzr export`` now takes an optional argument ``--per-file-timestamps``
+ to set file mtimes to the last timestamp of the last revision in which
+ they were changed rather than the current time. (Jelmer Vernooij)
+
+* If the Apport crash-reporting tool is available, bzr crashes are now
+ stored into the ``/var/crash`` apport spool directory, and the user is
+ invited to report them to the developers from there, either
+ automatically or by running ``apport-bug``. No information is sent
+ without specific permission from the user. (Martin Pool, #515052)
+
+* Parsing of command lines, for example in ``diff --using``, no longer
+ treats backslash as an escape character on Windows.
+ (Gordon Tyler, #392428)
+
+* Plugins can be disabled by defining ``BZR_DISABLE_PLUGINS`` as
+ a list of plugin names separated by ':' (';' on windows).
+ (Vincent Ladeuil, #411413)
+
+* Plugins can be loaded from arbitrary locations by defining
+ ``BZR_PLUGINS_AT`` as a list of name@path separated by ':' (';' on
+ windows). This takes precedence over ``BZR_PLUGIN_PATH`` for the
+ specified plugins. This is targeted at plugin developers for punctual
+ needs and *not* intended to replace ``BZR_PLUGIN_PATH``.
+ (Vincent Ladeuil, #82693)
+
+* Tag names can now be determined automatically by ``automatic_tag_name``
+ hooks on ``Branch`` if they are not specified on the command line.
+ (Jelmer Vernooij)
+
+* Tree-shape conflicts can be resolved by providing ``--take-this`` and
+ ``--take-other`` to the ``bzr resolve`` command. Just marking the conflict
+ as resolved is still accessible via the ``--done`` default action.
+ (Vincent Ladeuil)
+
+* Merges can be proposed on Launchpad with the new lp-propose-merge command.
+ (Aaron Bentley, Jonathan Lange)
+
+Bug Fixes
+*********
+
+* Added docstring for ``Tree.iter_changes``
+ (John Arbash Meinel, #304182)
+
+* Allow additional arguments to
+ ``RemoteRepository.add_inventory_by_delta()``. (Jelmer Vernooij, #532631)
+
+* Allow exporting a single file using ``bzr export``.
+ (Michal Junák, #511987)
+
+* Allow syscalls to automatically restart when ``TextUIFactory``'s
+ SIGWINCH handler is invoked, avoiding ``EINTR`` errors during blocking
+ IO, which are often poorly handled by Python's libraries and parts of
+ bzrlib. (Andrew Bennetts, #496813)
+
+* Avoid infinite recursion when probing for apport.
+ (Vincent Ladeuil, #516934)
+
+* Avoid ``malloc(0)`` in ``patiencediff``, which is non-portable.
+ (Martin Pool, #331095)
+
+* Avoid truncating svn URLs.
+ (Martin Pool, Martin von Gagern, #545185)
+
+* ``bzr add`` will not add conflict related files unless explicitly required.
+ (Vincent Ladeuil, #322767, #414589)
+
+* ``bzr dump-btree`` now works on ``*.cix`` and ``*.six`` files. Those
+ indices do not have reference lists, so ``dump-btree`` will simply show
+ ``None`` instead. (Andrew Bennetts, #488607)
+
+* ``bzr help`` will no longer trigger the get_missing_command hook when
+ doing a topic lookup. This avoids prompting (like 'no command plugins/loom,
+ did you mean log?') when getting help. In future we may trigger the hook
+ deliberately when no help topics match from any help index.
+ (Robert Collins, #396261)
+
+* ``bzr log -n0 -r..A.B.C`` should not crash but just consider the None
+ revspec as representing the first revision of the branch.
+ (Vincent Ladeuil, #519862)
+
+* ``bzr remove-tree`` can now remove multiple working trees.
+ (Jared Hance, Andrew Bennetts, #253137)
+
+* ``bzr resolve --take-this`` and ``--take-other`` now correctly renames
+ the kept file on content conflicts where one side deleted the file.
+ (Vincent Ladeuil, #529968)
+
+* ``bzr upgrade`` now creates the ``backup.bzr`` directory with the same
+ permissions as ``.bzr`` directory on a POSIX OS.
+ (Parth Malwankar, #262450)
+
+* ``bzr upgrade`` now names backup directory as ``backup.bzr.~N~`` instead
+ of ``backup.bzr``. This directory is ignored by bzr commands such as
+ ``add``.
+ (Parth Malwankar, #335033, #300001)
+
+* Cope with non-utf8 characters inside ``.bzrignore``.
+ (Jason Spashett, #183504)
+
+* Correctly interpret "451 Rename/move failure: Directory not empty" from
+ FTP servers while trying to take a lock.
+ (Martin Pool, #528722)
+
+* DirStateRevisionTree.kind() was returning wrong result when 'kind'
+ changes occured between the workingtree and one of its parents.
+ (Vincent Ladeuil, #535547)
+
+* Fix ``log`` to better check ancestors even if merged revisions are involved.
+ (Vincent Ladeuil, #476293)
+
+* Loading a plugin from a given path with ``BZR_PLUGINS_AT`` doesn't depend
+ on os.lisdir() order and is now reliable.
+ (Vincent Ladeuil, #552922).
+
+* Many IO operations that returned ``EINTR`` were retried even if it
+ wasn't safe to do so via careless use of ``until_no_eintr``. Bazaar now
+ only retries operations that are safe to retry, and in some cases has
+ switched to operations that can be retried (e.g. ``sock.send`` rather than
+ ``sock.sendall``).
+ (Andrew Bennetts, Martin <gzlist@googlemail.com>, #496813)
+
+* Path conflicts now support --take-this and --take-other even when a
+ deletion is involved.
+ (Vincent Ladeuil, #531967)
+
+* Network transfer amounts and rates are now displayed in SI units according
+ to the Ubuntu Units Policy <https://wiki.ubuntu.com/UnitsPolicy>.
+ (Gordon Tyler, #514399)
+
+* Support kind markers for socket and fifo filesystem objects. This
+ prevents ``bzr status --short`` from crashing when those files are
+ present. (John Arbash Meinel, #303275)
+
+* ``bzr mkdir DIR`` will not create DIR unless DIR's parent is a versioned
+ directory. (Parth Malwankar, #138600)
+
+* SSH child processes will now ignore SIGQUIT on nix systems so breaking into
+ the debugger won't kill the session.
+ (Martin <gzlist@googlemail.com>, #162502)
+
+* Tolerate patches with leading noise in ``bzr-handle-patch``.
+ (Toshio Kuratomi, Martin Pool, #502076)
+
+* ``update -r`` now supports updating to revisions that are not on
+ mainline (i.e. it supports dotted revisions).
+ (Parth Malwankar, #517800)
+
+* Use first apparent author not committer in GNU Changelog format.
+ (Martin von Gagern, #513322)
+
+API Changes
+***********
+
+* ``bzrlib.merge_directive._BaseMergeDirective`` has been renamed to
+ ``bzrlib.merge_directive.BaseMergeDirective`` and is now public.
+ (Jelmer Vernooij)
+
+* ``BranchFormat.initialize`` now takes an optional ``name`` of the colocated
+ branch to create. (Jelmer Vernooij)
+
+* ``BzrDir.get_branch_transport`` now takes an optional ``name`` of the
+ colocated branch to open. (Jelmer Vernooij)
+
+* Added ``bzrlib.osutils.set_signal_handler``, a convenience function that
+ can set a signal handler and call ``signal.siginterrupt(signum,
+ False)`` for it, if the platform and Python version supports it.
+ (Andrew Bennetts, #496813)
+
+* New ``bzrlib.initialize`` is recommended for programs using bzrlib to
+ run when starting up; it sets up several things that previously needed
+ to be done separately.
+ (Martin Pool, #507710)
+
+* Exporters now support a ``per_file_timestamps`` argument to write out the
+ timestamp of the commit in which a file revision was introduced.
+ (Jelmer Vernooij)
+
+* New method ``BzrDir.list_branches()`` that returns a sequence of branches
+ present in a control directory. (Jelmer Vernooij)
+
+* New method ``Repository.get_known_graph_ancestry()``.
+ (Jelmer Vernooij, #495502)
+
+* New transport methods ``readlink``, ``symlink`` and ``hardlink``.
+ (Neil Santos)
+
+* Remove unused ``CommandFailed`` exception.
+ (Martin Pool)
+
+Internals
+*********
+
+* ``bzrlib.branchbuilder.BranchBuilder.build_snapshot`` now accepts a
+ ``message_callback`` in the same way that commit does. (Robert Collins)
+
+* ``bzrlib.builtins.Commit.run`` raises ``bzrlib.errors.BoundBranchOutOfDate``
+ rather than ``bzrlib.errors.BzrCommandError`` when the bound branch is out
+ of date. (Gary van der Merwe)
+
+* ``bzrlib.commands.run_bzr`` is more extensible: callers can supply the
+ functions to load or disable plugins if they wish to use a different
+ plugin mechanism; the --help, --version and no-command name code paths
+ now use the generic pluggable command lookup infrastructure.
+ (Robert Collins)
+
+* ``bzrlib.errors.BoundBranchOutOfDate`` has a new field ``extra_help``
+ which can be set to add extra help to the error. (Gary van der Merwe)
+
+* New method ``Branch.automatic_tag_name`` that can be used to find the
+ tag name for a particular revision automatically. (Jelmer Vernooij)
+
+* The methods ``BzrDir.create_branch()``, ``BzrDir.destroy_branch()`` and
+ ``BzrDir.open_branch()`` now take an optional ``name`` argument.
+ (Jelmer Vernooij)
+
+Testing
+*******
+
+* bzr now has a ``.testr.conf`` file in its source tree configured
+ appropriately for running tests with Testrepository
+ (``https://launchpad.net/testrepository``). (Robert Collins)
+
+* Documentation about testing with ``subunit`` has been tweaked.
+ (Robert Collins)
+
+* Known failures has been added for resolve --take-other on ParentLoop
+ conflicts. This reflects bug #537956 without fixing it.
+ (Vincent Ladeuil)
+
+* New ``bzrlib.tests.test_import_tariff`` can make assertions about what
+ Python modules are loaded, to guard against startup time or library
+ dependency regressions.
+ (Martin Pool)
+
+* PQM will now run with subunit output. To analyze a PQM error use
+ tribunal, or cat log | subunit-filter | subunit2pyunit. (Robert Collins)
+
+* Stop sending apport crash files to ``.cache`` in the directory from
+ which ``bzr selftest`` was run. (Martin Pool, #422350)
+
+* Tests no longer fail if "close() called during concurrent
+ operation on the same file object" occurs when closing the log file
+ (which can happen if a thread tries to write to the log file at the
+ wrong moment). An warning will be written to ``stderr`` when this
+ happens, and another warning will be written if the log file could not
+ be closed after retrying 100 times. (Andrew Bennetts, #531746)
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-2.3.txt b/doc/en/release-notes/bzr-2.3.txt
new file mode 100644
index 0000000..db764b5
--- /dev/null
+++ b/doc/en/release-notes/bzr-2.3.txt
@@ -0,0 +1,1235 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 2.3.5
+#########
+
+:2.3.5: NOT RELEASED YET
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Cope cleanly with buggy HTTP proxies that close the socket in the middle
+ of a multipart response. (Martin Pool, #198646).
+
+* cStringIO is now unconditionally imported in ``bzrlib.config``.
+ (Jelmer Vernooij, #905361)
+
+* Fix "Unprintable exception" error when a RetryWithNewPacks error is
+ displayed. (Andrew Bennetts)
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+
+bzr 2.3.4
+#########
+
+:Codename: One and counting
+:2.3.4: 2011-07-14
+
+This is a bugfix release. Upgrading is recommended for all users of earlier
+2.3 releases.
+
+This mainly fixes bug #786980 which blocked the SRU process for Ubuntu Natty.
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+* Tweak an RPC implementation for ``Repository.get_parent_map``, it was
+ doing an inefficient ``small_set.difference_update(large_set)`` when we
+ can do ``small_set = small_set.difference(large_set)``. This speeds up
+ discovery time by about 10%. (John Arbash Meinel)
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Accept some differences for ``bound_location`` from the config files that
+ were leading to a 'ReadOnlyError: A write attempt was made in a read only
+ transaction' error. (Vincent Ladeuil, #786980)
+
+* Don't fail with traceback if `bzr serve` is running as a service on Windows,
+ and there is no USERNAME, nor BZR_EMAIL or other whoami-related environment
+ variables set. (Alexander Belchenko, Bug #660174)
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+* Updated the "Using stacked branches" section of the user guide to
+ describe committing to stacked branches and expanded its discussion of
+ pushing a stacked branch. (Andrew Bennetts)
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+* Remove the deprecation decorators for ``failUnlessExists`` and
+ ``failIfExists``. The deprecation "will" occur in 2.4, not
+ before. Providing the wrappers is enough as far as 2.3 is concerned.
+ (Vincent Ladeuil #794960)
+
+bzr 2.3.3
+#########
+
+:2.3.3: 2011-05-13
+
+This is a bugfix release. Upgrading is recommended for all users of earlier
+2.3 releases.
+
+This fixed a bug in the test suite triggered by python-2.7 deprecating some
+tests helpers.
+
+Testing
+*******
+
+* Stop using `failIf`, `failUnless`, `failIfEqual`, etc, that give
+ `PendingDeprecationWarnings` on Python2.7.
+ (Martin Pool, #760435)
+
+
+bzr 2.3.2
+#########
+
+:2.3.2: 2011-05-12
+
+This is a bugfix release. Upgrading is recommended for all users of earlier
+2.3 releases.
+
+This was never released due to bug #760435 interrupting the release process by
+breaking the test suite under python-2.7 on natty.
+
+External Compatibility Breaks
+*****************************
+
+None
+
+New Features
+************
+
+None
+
+Improvements
+************
+
+* Getting all entries from ``CHKInventory.iter_entries_by_dir()`` has been
+ sped up dramatically for large trees. Iterating by dir is not the best
+ way to load data from a CHK inventory, so it preloads all the items in
+ the correct order. (With the gcc-tree, this changes it (re)reading 8GB
+ of CHK data, down to just 150MB.) This has noticeable affects for things
+ like building checkouts, etc. (John Arbash Meinel, #737234)
+
+Bug Fixes
+*********
+
+* Bazaar now infers the default user email address on Unix from the local
+ account name plus the contents of ``/etc/mailname`` if that file exists.
+ In particular, this means that committing as root through etckeeper will
+ normally not require running ``bzr whoami`` first.
+ (Martin Pool, #616878)
+
+* ``bzr merge --preview --pull`` should respect the ``--preview`` option
+ first, and not actually change the branch tip revision.
+ (John Arbash Meinel, Dennis Duchier, #760152)
+
+* ``bzr push`` into a repository (that doesn't have a branch), will no
+ longer copy all revisions in the repository. Only the ones in the
+ ancestry of the source branch, like it does in all other cases.
+ (John Arbash Meinel, #465517)
+
+* Fix ``UnboundLocalError: local variable 'lock_url' in wait_lock`` error,
+ especially while trying to save configuration from QBzr.
+ (Martin Pool, #733136)
+
+* Fix "Unable to obtain lock" error when pushing to a bound branch if tags
+ had changed. Bazaar was attempting to open and lock the master branch
+ twice in this case. (Andrew Bennetts, #733350)
+
+* Standalone bzr.exe installation on Windows: user can put additional python
+ libraries into ``site-packages`` subdirectory of the installation directory,
+ this might be required for "installing" extra dependencies for some plugins.
+ (Alexander Belchenko, #743256)
+
+* When reporting a crash without apport, don't print the full list of
+ plugins because it's often too long.
+ (Martin Pool, #716389)
+
+
+API Changes
+***********
+
+None.
+
+Testing
+*******
+
+* FreeBSD8 has switched to python-2.7 which revealed a re-occurrence of a test
+ failure in the launchpad plugin. ``xmlrpclib.py`` on natty carries a patch
+ that is not in python-2.7 upstream and masked the issue. An additional fix
+ has been added in the interim
+ (<http://psf.upfronthosting.co.za/roundup/tracker/issue8194> should be fixed
+ in python > 2.7.1). (Vincent Ladeuil, #654733)
+
+bzr 2.3.1
+#########
+
+:2.3.1: 2011-03-10
+
+This is a bugfix release. Upgrading is recommended for all users of earlier
+2.3 releases.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Correctly resolve text conflicts for files in subdirs.
+ (Vincent Ladeuil, #715058)
+
+* Fix "AssertionError: repository.user_url ... does not match URL from
+ server response" when reusing a smart transport.
+ (Andrew Bennetts, #726584)
+
+* Restore proper logging of bytes transferred. We accidentally reset the
+ counter when commands finished before we logged the total transferred.
+ (John Arbash Meinel, #713258)
+
+bzr 2.3.0
+#########
+
+:2.3.0: 2011-02-03
+
+This release marks the start of another long-term-stable series. From here, we
+will only make bugfix releases on the 2.3 series (2.3.1, etc, and support it
+until August 2012), while 2.4 will become our new development series. The 2.1
+and 2.2 series will also continue to get bugfixes. (Currently 2.0 is planned
+to be EOLed circa September 2011 and will receive only critical bugfixes.)
+
+This is a bugfix and polish release over the 2.2 series, with a large number
+of bugs fixed (>130), and some performance improvements. Some features have
+been enhanced including commits on stacked branches, upgrades of related
+branches, shortcut URL schemes for ubuntu and debian on launchpad and better
+conflict resolution.
+
+Only bugfixes from other stables series have been included since 2.3b5 so all
+known fixed bugs are included here.
+
+Users are encouraged to upgrade from the other stable series.
+
+bzr 2.3b5
+#########
+
+:2.3.b5: 2011-01-13
+
+This is the fifth and **last** beta of the 2.3 series, leading up to a 2.3.0
+release in February. Beta releases are suitable for everyday use but may cause
+some incompatibilities with plugins.
+
+2.3b5 includes bug fixes for committing to stacked branches, smoother upgrades
+of multiple branches, compatibility with python-2.7, full test suite passing
+on Ubuntu Natty and windows, less round-trips for several smart server
+operations, better support text conflicts resolve actions and some more.
+
+All known fixed bugs in other series (2.0, 2.1, 2.2) are also included here.
+
+External Compatibility Breaks
+*****************************
+
+(none)
+
+Improvements
+************
+
+* A redundant parent inventories calculation was removed from
+ ``fetch.py``, as ``Repository.insert_stream`` already reports any
+ missing inventories. This removes at least one network roundtrip when
+ pushing to a stacked branch. (Andrew Bennetts)
+
+* ``ControlDir.sprout`` no longer opens the target repository more than
+ once. This avoids some unnecessary IO, and removes a network roundtrip
+ when doing ``bzr branch`` to a smart server URL. (Andrew Bennetts)
+
+* ``bzr modified`` now read-locks the working tree (and branch and
+ repository) just once. (Andrew Bennetts)
+
+* ``bzr resolve`` now accepts ``--take-this`` and ``--take-other`` actions
+ for text conflicts. This *replace* the whole file with the content
+ designated by the action. This will *ignore* all differences that would
+ have been merge cleanly otherwise. (Vincent Ladeuil, #638451)
+
+* ``bzr tags``'s "sort" argument now allows registering custom sort
+ methods using the ``bzrlib.tag.tag_sort_methods`` registry.
+ (Jelmer Vernooij, #701244)
+
+* ``bt.test_http`` was breaking ``os.environ`` by erasing the values saved by
+ ``TestCase`` leading to ``bt.test_import_tariff`` failures.
+ (Vincent Ladeuil, #690563)
+
+* ``upgrade`` now upgrades dependent branches when a shared repository is
+ specified. It also supports new options: ``--dry-run`` for showing what
+ will happen and ``--clean`` to remove the backup directory on successful
+ completion. (Ian Clatworthy, Matthew Fuller, #89830, #374734, #422450)
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Avoid leaking SSH subprocess communication socket into unrelated child
+ processes, which could cause bzr to hang on exit. (Max Bowsher, #696285)
+
+* ``bzr break-lock`` on a corrupted lock file works correctly, rather than
+ raising a PermissionDenied error. We were accidentally holding open the
+ file we were trying to delete. (John Arbash Meinel, #659978)
+
+* ``bzr update`` in a checkout of a readonly branch works again, without
+ trying to set the tags in the master branch. This had been broken by the
+ bug fix for bug #603395. (John Arbash Meinel, #701212)
+
+* Per-transport tests now prefer to use ``Transport.get_bytes()`` rather
+ than ``Transport.get().read()``. The SFTP code uses an async message to
+ close the file handle if you let the handle die from refcounting, while
+ it uses a synchronous message if you close it directly. This should help
+ prevent random test suite failures from race conditions.
+ (John Arbash Meinel, #681047)
+
+* Stop using ``bzrlib.tuned_gzip.GzipFile``. It is incompatible with
+ python-2.7 and was only used for Knit format repositories, which haven't
+ been recommended since 2007. The file itself will be removed in the next
+ release. (John Arbash Meinel)
+
+* The BZR_COLUMNS environment variable can be set to 0 to indicate no
+ limitation on the width of the terminal. (Neil Martinsen-Burrell, #675652)
+
+* Treat WSAECONNABORTED the same as WSAECONNRESET for the purposes of
+ considering a smart data stream as being interrupted. This fixes a
+ failure in the windows test suite, that was trying to ensure we cleanly
+ handled a server disconnect. (John Arbash Meinel, #581311, #686587)
+
+* Unshelving changes that occur in a now-unversioned directory now restore
+ the directory properly rather than crashing.
+ (John Arbash Meinel, #389674)
+
+* You are now able to commit directly to a stacked branch. Any needed
+ parent inventories will be filled in as part of the commit process.
+ (John Arbash Meinel, #375013)
+
+Documentation
+*************
+
+* Better document the rules to update the bzr freshmeat page when
+ doing a release. (Vincent Ladeuil, #690515)
+
+API Changes
+***********
+
+* ``Branch.sprout``, ``BranchFormat.initalize`` and
+ ``ControlDir.create_branch`` now take an optional ``repository`` keyword
+ argument, and ``BranchFormat.open`` now takes an optional
+ ``found_repository`` keyword argument. These provide the repository
+ object for new branch object to use (for cases when the caller has
+ already opened that repository). Implementations of these APIs will
+ need to be updated to accept these arguments. (Andrew Bennetts)
+
+* ``bzrlib.tuned_gzip.GzipFile`` is now deprecated and will be removed in
+ the bzr-2.4 series. Code that was using it can just use the python
+ stdlib ``gzip.GzipFile``. (John Arbash Meinel)
+
+
+Testing
+*******
+
+* ``bzrlib.tests`` defines ``isolated_environ`` with the definitions of all
+ the environment variables the tests should care about. It also defines
+ ``override_os_environ`` and ``restore_os_environ`` to properly implement
+ isolation from ``os.environ`` for tests. ``bzrlib.tests`` now defines a
+ ``DocTestSuite`` class using this facility for all ``bzrlib``
+ doctests. (Vincent Ladeuil, #321320)
+
+* Catch exceptions related to bug #637821 during test cleanup to avoid
+ spurious failures. (Vincent Ladeuil, #686008).
+
+* Check sphinx compatibility for tests requiring older sphinx versions.
+ (Vincent Ladeuil, #688072)
+
+* ``test_onto_transport`` in the Launchpad plugin can now run with Python
+ 2.7. (Vincent Ladeuil, #654733)
+
+* ``TestCase._captureVar`` and ``TestCase._old_env`` have been deleted due to
+ bug #690563. Test writers are encouraged to use ``TestCase.overrideEnv``
+ instead. (Vincent Ladeuil)
+
+* ``TestDebuntuExpansions`` was escaping the test isolation by calling the
+ wrong base class ``setUp``. (Vincent Ladeuil, #684662)
+
+bzr 2.3b4
+#########
+
+:2.3.b4: 2010-12-03
+
+This is the fourth beta of the 2.3 series, leading up to a 2.3.0 release in
+February. Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins.
+
+2.3b4 includes bug fixes for the ``config`` command and conflict
+resolution. More changes were made for the test scripts handling to make it
+easier to add reproducing recipes to bugs.
+
+It also includes bug fixes from the 2.2.2 release as well as the bug fixes
+in the upcoming 2.0.7, 2.1.4 and 2.2.3 releases. This means that all known
+fixed bugs at the time of this release are included.
+
+
+External Compatibility Breaks
+*****************************
+
+ (none)
+
+Improvements
+************
+
+* Bazaar now caches a branch's tags while that branch is read-locked.
+ This removes 1 network roundtrip from most interactions with a remote
+ branch. (Andrew Bennetts)
+
+* ``bzr config <option>`` will now display only the value itself so scripts
+ can use it to query the currently active configuration. Displaying several
+ options matching a given regular expression is now controlled via the
+ ``--all`` option. (Vincent Ladeuil, bug #670251)
+
+* ``bzr resolve`` now reports the number of conflicts resolved and the
+ number of remaining conflicts. This provides a better feedback about the
+ whole resolution process. (Vincent Ladeuil)
+
+* Read configuration files in $XDG_CONFIG_HOME/bazaar on Unix if there is
+ already a directory there. (Neil Martinsen-Burrell, #195397)
+
+Bug Fixes
+*********
+
+* Better message if there is an error while setting ownership of
+ ``.bazaar`` directory. (Parth Malwankar, #657553)
+
+* ``bzr config`` properly displays list values. (Vincent Ladeuil, #672382)
+
+* ``bzr config`` will now respect option policies when displaying the value
+ and display the definition sections when appropriate.
+ (Vincent Ladeuil, #671050)
+
+* Don't create commit message files in the current directory to avoid nasty
+ interactions with emacs (which tries to establish the status of the file
+ during the commit which breaks on windows). (Vincent Ladeuil, #673637)
+
+* ``bzr resolve --take-other <file>`` will not crash anymore if ``<file>``
+ is involved in a text conflict (but the conflict is still not
+ resolved). (Vincent Ladeuil, #646961)
+
+* Merge will now correctly locate a lca where there is a criss-cross merge
+ of a new root. (Gary van der Merwe, #588698)
+
+* Report error if non-ASCII command option given. (Rory Yorke, #140563)
+
+* ``tools/check-newsbug.py`` is now based on ``lp:hydrazine`` and no longer
+ crashes when encountering private bugs (they are just displayed as such).
+ (Vincent Ladeuil, #354985)
+
+Internals
+*********
+
+* ``BranchBuilder.build_snapshot`` now accepts parent_ids == [].
+ This can be used to create a new root in the graph. (Gary van der Merwe)
+
+* Old repository development formats
+ RepositoryFormatCHK1 and RepositoryFormatCHK2 have been removed, and so
+ have the corresponding metadir format options ``development-rich-root``,
+ ``development6-rich-root``, and ``development7-rich-root``.
+
+Testing
+*******
+
+* Add a null_output_matches_anything keyword argument with default False to
+ bzrlib.tests.script.ScriptRunner.run_script to specify that the command
+ output should not be checked (as opposed to expecting an empty output).
+ (Neil Martinsen-Burrell, #662509)
+
+* Blank output section in scriptrunner tests no longer match any output.
+ Instead, use '...' as a wildcard if you don't care about the output.
+ (Martin Pool, #637830)
+
+* Bump minimum testtools version required to run ``bzr selftest`` from 0.9.2
+ to 0.9.5 which will allow tests that need the fixed unicode handling to be
+ written. (Martin [gz])
+
+* Introduce an ``overrideEnv()`` helper for tests that needs to change the
+ environment variables while respecting the isolation rules. Get rid of
+ TestCase._restoreEnvironment which is now useless.
+ (Vincent Ladeuil, #690563)
+
+* Printing selftest results to a non-UTF-8 console will now escape characters
+ that can't be encoded rather than aborting the test run with an exception.
+ (Martin [gz], #633216)
+
+
+bzr 2.3b3
+#########
+
+:2.3b3: 2010-11-05
+
+External Compatibility Breaks
+*****************************
+
+(none)
+
+New Features
+************
+
+* Add --no-tree option to 'bzr push' and 'bzr init' for creating a
+ new or mirrored branch without working trees.
+ (Matthew Gordon, #506730)
+
+* ``bzr config`` is a new command that displays the configuration options for
+ a given directory. It accepts a glob to match against multiple options at
+ once. It can also be used to set or delete a configuration option in any
+ configuration file. (Vincent Ladeuil)
+
+* New shortcut URL schemes ``ubuntu:`` and ``debianlp:`` access source
+ branches on Launchpad. E.g. ``bzr branch ubuntu:foo`` gives you the source
+ branch for project ``foo`` in the current distroseries for Ubuntu while
+ ``bzr branch debianlp:lenny/foo`` gives you the source branch (on Launchpad)
+ for project ``foo`` in Debian Lenny.
+ (Barry Warsaw, #609186)
+
+* Provide a configuration option "default_format" that controls the
+ default format for new branches created with ``bzr init``.
+ (Neil Martinsen-Burrell, #484101)
+
+Bug Fixes
+*********
+
+* Always set PATH in start_bzr.bat on Windows. (Matthäus G. Chajdas, #470264)
+
+* ``bzr status -r X..Y`` was failing because RevisionTree didn't implement
+ ``get_shelf_manager``. (John Arbash Meinel, #662053)
+
+* Correctly add directory contents when the name was previously added as a
+ normal file, rather than throwing ``AttributeError: children`` during
+ smart_add. (Martin [gz], #251864)
+
+* Correctly handle the ``--directory`` option for all code paths of
+ ``resolve`` and ``shelve``, this was previously ignored when paths were
+ provided as parameters. When both are provided, ``--directory`` becomes
+ the base directory for the other paths. (Vincent Ladeuil, #670851)
+
+* Correctly set the Content-Type header when HTTP POSTing to comply
+ with stricter web frameworks. (Vincent Ladeuil, #665100)
+
+* Don't force openssh to use protocol=2, since that is now the default.
+ (Neil Martinsen-Burrell, #561061)
+
+* Fix ``KeyError: 'port'`` when getting the stored password for an HTTP URL.
+ (Martin Pool, #654684)
+
+* Make ``bzr tag --quiet`` really quiet. (Neil Martinsen-Burrell, #239523)
+
+* Missing files (files bzr add'ed and then OS deleted) are now shown in ``bzr
+ status`` output. (Rory Yorke, #134168)
+
+* ``NotBranchError`` no longer allows errors from calling
+ ``bzrdir.open_repository()`` to propagate. This is unhelpful at best,
+ and at worst can trigger infinite loops in callers. (Andrew Bennetts)
+
+* The ``branch.tags.merge_to(target_branch)`` API used by plugins such as
+ ``bzr-builddeb`` now propagates changes to the master branch of the
+ target branch (if there is one). This makes it consistent with the
+ other tag APIs. (Andrew Bennetts, #603395)
+
+* Windows installers no longer requires the Microsoft vcredist to be
+ installed. (Martin [gz], Gary van der Merwe, #632465)
+
+Documentation
+*************
+
+* Add documentation of the ability to edit hunks when shelving.
+ (Neil Martinsen-Burrell, #517660)
+
+* Be more specific about the meaning of revision ranges for ``bzr diff``.
+ (Neil Martinsen-Burrell, #247282)
+
+* Document the comment character in the .bzrignore file, including a
+ workaround for ignore patterns that begin with #.
+ (Neil Martinsen-Burrell, #631515)
+
+API Changes
+***********
+
+* Add ``bzrlib.pyutils`` module with helper functions for some Python
+ tasks such as resolving a dotted name to a Python object
+ (``get_named_object``). (Andrew Bennetts)
+
+* ``bzrlib.tests.ForwardingResult`` no longer exists. Use
+ ``testtools.ExtendedToOriginalDecorator`` instead. (Andrew Bennetts)
+
+* ``known_hooks_key_to_parent_and_attribute`` in ``bzrlib.hooks`` has been
+ deprecated in favour of ``known_hooks.key_to_parent_and_attribute`` in
+ the same module. (Andrew Bennetts)
+
+Internals
+*********
+
+* ``tools/fixed-in.py`` find a bug in NEWS from its number or a regexp
+ matching the news entry and display the corresponding release, date, fix
+ authors and the news entry itself. (Vincent Ladeuil)
+
+Testing
+*******
+
+* Blank output section in scriptrunner tests no longer match any output.
+ Instead, use '...' as a wildcard if you don't care about the output.
+ (Martin Pool, #637830)
+
+* ``bzr test-script script`` is a new command that runs a shell-like script
+ from an the ``script`` file. (Vincent Ladeuil)
+
+* Fix spurious test failures on babune related to the http pipe cleanup and
+ get rid of some 'bytes left on the HTTP socket' useless log messages.
+ (Vincent Ladeuil, #655557)
+
+* ``bzrlib.tests.per_workingtree.TestCaseWithWorkingTree.make_branch_builder``
+ respects its ``relpath`` parameter. (Vincent Ladeuil)
+
+bzr 2.3b2
+#########
+
+:2.3b2: 2010-10-08
+
+External Compatibility Breaks
+*****************************
+
+* The ``bzr tags`` command sorts tag names using a natural sort by
+ default (so tag2 sorts before tag10). The previous default was
+ strictly "asciibetical". That behavior is still available as ``bzr tags
+ --sort=alpha``. (Neil Martinsen-Burrell, #640760)
+
+* ``BzrDir.generate_backup_name`` has been deprecated and replaced by a
+ private method. ``osutils.available_backup_name`` provides an extensible
+ replacement. This allowed the deprecation of
+ ``bzrlib.transform.get_backup_name``,
+ ``bzrlib.transform._get_backup_name`` and
+ ``bzrlib.transform.TreeTransformBase.has_named_child``.
+ (Vincent Ladeuil)
+
+New Features
+************
+
+* Add ``mainline`` revision specifier, which selects the revision that
+ merged a specified revision into the mainline. (Aaron Bentley)
+
+* Add ``annotate`` revision specifier, which selects the revision that
+ introduced a specified line of a file. (Aaron Bentley)
+
+* Add ``-Dmem_dump`` debug flag, which uses meliae to dump memory to
+ a file upon an out of memory error.
+ (Karl Bielefeldt, #551391)
+
+* ``bzr status`` now displays a summary of existing shelves after
+ the other status information. This is done using a ``post_status``
+ hook.
+ (Parth Malwankar, #403687)
+
+* GNU lsh is now a supported lsh client; just set BZR_SSH to 'lsh'.
+ Also, bzr will recognize if the 'ssh' comand is a symlink to lsh.
+ (Matthew Gordon, #374700)
+
+* The ``pull`` and ``update`` commands now take a ``--show-base``
+ option that, in the case of conflicts, shows the base revision text.
+ (Rory Yorke, #202374)
+
+Improvements
+************
+
+* ``bzr break-lock --force`` breaks the lock without prompting. (Before
+ using this, make sure the process holding the lock really is dead.)
+ (Martin Pool, #397315)
+
+* ``bzr remove`` now takes a ``--no-backup`` option for when you don't want it
+ to backup anything, just delete it. This option used to be called ``--force``
+ which is now deprecated.
+ (Marius Kruger, #400554)
+
+* When using the pycurl client module, Bazaar shows some of the text from
+ HTTP server error messages.
+ (Martin Pool, #656667)
+
+Bug Fixes
+*********
+
+* Don't force openssh to use protocol=2, since that is now the default.
+ (Neil Martinsen-Burrell, #561061)
+
+* Fix signature of RemoteBzrDir.create_workingtree to match that of its
+ superclass. (Neil Martinsen-Burrell, Martin Pool, #524627)
+
+* Fix traceback with python-2.7's xmlrpclib
+ (Toshio Kuratomi, #612096)
+
+* Print junk rather than throwing a UnicodeDecodeError from ``bzr version-info``
+ when using the rio format (with non-ascii information) on a non-utf-8
+ terminal. (Andrej A Antonov, #518609)
+
+* Treat all IO, OS, and socket errors consistently when establishing
+ SSH/SFTP connections via a subprocess. (Andrew Bennetts)
+
+* ``unshelve --preview`` now can show diff in a non-ascii encoding.
+ (Andrej A Antonov, #518916)
+
+* Deleting a versioned directory can leave orphans: unversioned files that
+ were present don't have a parent anymore. The
+ ``bzr.transform.orphan_policy`` configuration option controls the ``bzr``
+ behaviour: ``conflict`` (the default) leave the orphans in place and
+ create a conflict for the directory, ``move`` create orphans named
+ ``<file>.~#~`` in a ``bzr-orphans`` directory at the root of the working
+ tree. (Vincent Ladeuil, #323111)
+
+Improvements
+************
+
+Documentation
+*************
+
+* Correct the documentation for setting up the smart server with Apache.
+ (Neil Martinsen-Burrell, #311518)
+
+* Fix rst typos in bzrlib/help_topics/en/conflict-types.txt.
+ (Vincent Ladeuil, #660943)
+
+* Provide more detailed help on the Launchpad plugin at "bzr help
+ plugins/launchpad". (Neil Martinsen-Burrell, #589379)
+
+* Suggest ``bzr revert`` for restoring locally deleted files in help text
+ for ``bzr update``. (John C Barstow, #191466)
+
+API Changes
+***********
+
+* ``WorkingTree`` methods ``pull``, ``update``, and ``_update_tree``
+ now have an optional argument, ``show_base``, which is by default
+ False. This is flag is ultimately passed to ``merge.merge_inner``
+ in each case. (Rory Yorke, #202374)
+
+Internals
+*********
+
+* Small change to GroupCompressBlock to work more in terms of 'chunks'
+ rather than 'content' for its compressed storage. (John Arbash Meinel)
+
+* When running ``bzr selftest --subunit`` the subunit stream will no
+ longer include the "log" information for tests which are considered to
+ be 'successes' (success, xfail, skip, etc) (John Arbash Meinel)
+
+Testing
+*******
+
+* Add a new simpler way to generate multiple test variations, by setting
+ the `scenarios` attribute of a test class to a list of scenarios
+ descriptions, then using `load_tests_apply_scenarios`. (See the testing
+ guide and `bzrlib.tests.scenarios`.) Simplify `test_http` using this.
+ (Martin Pool, #597791)
+
+* Add ``tests/ssl_certs/ca.crt`` to the required test files list. Test
+ involving the pycurl https test server fail otherwise when running
+ selftest from an installed version. (Vincent Ladeuil, #651706)
+
+* Fix tests that failed when run under ``LANG=C``.
+ (Andrew Bennetts, #632387)
+
+* Skip tests that needs a bzr source tree when there isn't one. This is
+ needed to successfully run the test suite for installed versions.
+ (Vincent Ladeuil, #644855).
+
+* Skip the tests that requires respecting the chmod bits when running as root.
+ (Vincent Ladeuil, #646133)
+
+* Suppress the "maximum recursion depth exceeded in __subclasscheck__"
+ warning on stderr emitted during ``test_dict_deepnested`` in
+ ``bzrlib/tests/test__bencode.py``. (Andrew Bennetts)
+
+* Use tests.TestCaseInTempDir for tests that requires disk resources.
+ (Vincent Ladeuil, #650001)
+
+bzr 2.3b1
+#########
+
+:2.3b1: 2010-09-20
+
+This is the first beta of the 2.3 series, leading up to a 2.3.0
+release in January or February. Beta releases are suitable for everyday use
+but may cause some incompatibilities with plugins. Some plugins may need
+small updates to work with 2.3b1.
+
+2.3b1 includes some performance improvements in both speed and memory
+consumption, some preliminary support for generating a texinfo version of
+the doc and better support for launchpad. Many changes were made to make
+our test suite more robust as well as numerous documentation fixes. It
+improves the common infrastructure for dealing with colocated named
+branches and foreign branches. We plan to continue with these themes
+through the 2.3 series.
+
+It also includes bug fixes for 2.0.6, 2.1.3 and 2.2.1 and over 40 fixes of
+its own.
+
+
+External Compatibility Breaks
+*****************************
+
+(none)
+
+New Features
+************
+
+* Added ``pre_status`` and ``post_status`` hooks. This allows plugins
+ to register custom handlers which will be invoked before/after the
+ standard status output is displayed. (Parth Malwankar)
+
+* ``bzr break-lock --config [location]`` can now break config files
+ locks. (Vincent Ladeuil, #525571)
+
+* ``bzrlib.config.LockableConfig`` is a base class for config files that
+ needs to be protected against multiple writers. All methods that
+ change a configuration variable value must be decorated with
+ @needs_write_lock (set_option() for example).
+ (Vincent Ladeuil, #525571)
+
+* The ``lp:`` prefix will now use your known username (from
+ ``bzr launchpad-login``) to expand ``~`` to your username. For example:
+ ``bzr launchpad-login user && bzr push lp:~/project/branch`` will now
+ push to ``lp:~user/project/branch``. (John Arbash Meinel)
+
+* New development format ``development8-subtree`` which is similar to the
+ ``2a`` format and adds subtree support. (Jelmer Vernooij)
+
+Improvements
+************
+
+* Allow using both ``--using`` and ``--diff-options``.
+ (Matthäus G. Chajdas, #234708)
+
+* Allow using non-integer bug ID with generic bug trackers.
+ (Alexandre Garnier, #440472)
+
+* ``bzr remove`` now just backs up changed files instead of exiting,
+ forcing you to choose to either keep or delete them. Bazaar will now delete
+ the files if they can easily be recovered using revert, otherwise they
+ will be backed up (adding an extension of the form .~#~).
+ (Marius Kruger, #400554)
+
+* ``bzr revert`` and ``bzr status`` are up to 15% faster on large trees
+ with many changes by not repeatedly building a list of all file-ids.
+ (Andrew Bennetts)
+
+* Decrease memory consumption when many chk index pages are loaded. (Such
+ as during ``bzr co`` or ``bzr ls -R`` of a large tree.) Often we need to
+ read many chk pages because the individual chk map nodes will be spread
+ randomly. Peak memory for 'bzr ls -R' on a large tree dropped from 396MB
+ down to 247MB, expect even more significant savings on 64-bit platforms.
+ (John Arbash Meinel)
+
+* Decrease peak memory during ``bzr send``. The old code was caching all
+ text content and all inventory strings for all revisions before
+ computing the diffs. Now we only cache as long as there is a child that
+ will need them. Sending 2000 bzr revisions drops from 1.2GB peak to
+ 256MB peak. (John Arbash Meinel, #614576)
+
+* ``DirState`` internals use a little bit less memory. For bzr.dev it
+ drops the memory from 1MB down to about 800kB. And replaces a few
+ thousand tuples and sets with StaticTuple. (John Arbash Meinel)
+
+* Inventory entries now consume less memory (on 32-bit Ubuntu file entries
+ have dropped from 68 bytes to 40, and directory entries from 120 bytes
+ to 48). (Andrew Bennetts)
+
+* Reduce peak memory by one copy of compressed text when writing to pack
+ repositories.
+ (John Arbash Meinel, #566940)
+
+* When building new working trees, default to reading from the repository
+ rather than the source tree unless explicitly requested. (via
+ ``--files-from`` and ``--hardlink`` for ``bzr branch`` and
+ ``bzr checkout``. Generally, 2a format repositories extract
+ content faster than seeking and reading content from another tree,
+ especially in cold-cache situations. (John Arbash Meinel, #607298)
+
+* Add ``__pycache__`` to the default ``ignores`` file. Future releases of
+ Python will use this directory to store bytecodes.
+ (Andrea Corbellini, #626687)
+
+Bug Fixes
+*********
+
+* Additional merges after an unrelated branch has been merged with its
+ history no longer crash when deleted files are involved.
+ (Vincent Ladeuil, John Arbash Meinel, #375898)
+
+* ``bzr add SYMLINK/FILE`` now works properly when the symlink points to a
+ previously-unversioned directory within the tree: the directory is
+ marked versioned too.
+ (Martin Pool, #192859)
+
+* ``bzr clean-tree`` issues a warning if it is unable to delete a file
+ due to ``errno.EACCES`` instead of exiting with an error on Windows.
+ (Parth Malwankar, #430785)
+
+* ``bzr commit SYMLINK`` now works, rather than trying to commit the
+ target of the symlink.
+ (Martin Pool, John Arbash Meinel, #128562)
+
+* ``bzr ignore PATTERNS`` exits with error if a bad pattern is supplied.
+ ``InvalidPattern`` exception error message now shows faulting
+ regular expression.
+ (Parth Malwankar #300062)
+
+* ``bzr upgrade`` now creates the ``backup.bzr`` directory with the same
+ permissions as ``.bzr`` directory on a POSIX OS.
+ (Parth Malwankar, #262450)
+
+* CommitBuilder now uses the committer instead of _config.username to generate
+ the revision-id. (Aaron Bentley, #614404)
+
+* Configuration files in ``${BZR_HOME}`` are now written in an atomic
+ way which should help avoid problems with concurrent writers.
+ (Vincent Ladeuil, #525571)
+
+* CommitBuilder now uses the committer instead of _config.username to generate
+ the revision-id. (Aaron Bentley, #614404)
+
+* Configuration files in ``${BZR_HOME}`` are now protected against
+ concurrent writers by using a lock. (Vincent Ladeuil, #525571)
+
+* Cope with Microsoft FTP Server and VSFTPd that return reply '250
+ Directory created' when mkdir succeeds. (Martin Pool, #224373)
+
+* `decode` parameter to get() method in FtpTransport and GioTransport classes
+ is deprecated. (Alexander Belchenko)
+
+* Don't print internal object name when print an invalid revision spec
+ error. (Neil Martinsen-Burrell, #598701)
+
+* Don't traceback when a lockdir's ``held/info`` file is corrupt (e.g.
+ contains only NUL bytes). Instead warn the user, and allow ``bzr
+ break-lock`` to remove it. (Andrew Bennetts, #619872)
+
+* ``EPIPE`` can be raised during test server shutdown. This happened on
+ gentoo only so far. (Vincent Ladeuil, #627277)
+
+* Errors occurring during HTTP(S) test server starts should now be
+ handled cleanly. (Vincent Ladeuil, #392402)
+
+* Fix ``AttributeError on parent.children`` when adding a file under a
+ directory that was a symlink in the previous commit.
+ (Martin Pool, #192859)
+
+* Fix ``AttributeError: 'NoneType' object has no attribute 'close'`` in
+ ``_close_ssh_proc`` when using ``bzr+ssh://``. This was causing
+ connections to pre-1.6 bzr+ssh servers to fail, and causing warnings on
+ stderr in some other circumstances. (Andrew Bennetts, #633745)
+
+* Fix spurious paramiko warning on hardy by ensuring that ``selftest``
+ properly remove its warning filter. (Vincent Ladeuil, #625686)
+
+* Fix ``AttributeError on parent.children`` when adding a file under a
+ directory that was a symlink in the previous commit.
+ (Martin Pool, #192859)
+
+* Fix ``AttributeError: 'NoneType' object has no attribute 'close'`` in
+ ``_close_ssh_proc`` when using ``bzr+ssh://``. This was causing
+ connections to pre-1.6 bzr+ssh servers to fail, and causing warnings on
+ stderr in some other circumstances. (Andrew Bennetts, #633745)
+
+* Fix a problem in bzr's ``Makefile`` that meant syntax errors in some
+ parts of bzr's source code could cause ``make check-nodocs`` to
+ incorrectly return an exit code of 0.
+ (Vincent Ladeuil, #626667)
+
+* ``HTTP/1.1`` test servers now set a ``Content-Length`` header to comply
+ with pedantic ``HTTP/1.1`` clients. (Vincent Ladeuil, #568421)
+
+* Most of the leaked threads during selftest are now fixed, allowing the
+ full test suite to pass on gentoo.
+ (Vincent Ladeuil, #392127)
+
+* Only call ``setlocale`` in the bzr startup script on posix systems. This
+ avoids an issue with the newer windows C runtimes used by Python 2.6 and
+ later which can mangle bytestrings printed to the console.
+ (Martin [gz], #631350)
+
+* `PathNotChild` should not give a traceback.
+ (Martin Pool, #98735)
+
+* Prevent ``CHKMap.apply_delta`` from generating non-canonical CHK maps,
+ which can result in "missing referenced chk root keys" errors when
+ fetching from repositories with affected revisions.
+ (Andrew Bennetts, #522637)
+
+* Raise ValueError instead of a string exception.
+ (John Arbash Meinel, #586926)
+
+* Repositories accessed via a smart server now reject being stacked on a
+ repository in an incompatible format, as is the case when accessing them
+ via other methods. This was causing fetches from those repositories via
+ a smart server (e.g. using ``bzr branch``) to receive invalid data.
+ (Andrew Bennetts, #562380)
+
+* Selftest with versions of subunit that support ``stopTestRun`` will no longer
+ error. This error was caused by 2.0 not being updated when upstream
+ python merged the end of run patch, which chose ``stopTestRun`` rather than
+ ``done``. (Robert Collins, #571437)
+
+* Stop ``AttributeError: 'module' object has no attribute 'ElementTree'``
+ being thrown from ``xml_serializer`` on certain cElementTree setups.
+ (Martin [gz], #254278)
+
+* strace test-helper tests cope with the new Ubuntu policy of not allowing
+ users to attach to their own processes by default.
+ (Martin Pool, #626679)
+
+* Test classes like ``TestCase``, ``TestLoader``, and ``TestSuite`` should
+ be available from ``bzrlib.tests.*``. They used to be, but were
+ accidentally removed. (John Arbash Meinel, #627438)
+
+* ``Transport.stat`` on a symlink, including a transport pointing directly
+ to a symlink, now returns information about the symlink.
+ (Martin Pool)
+
+* Upgrading or fetching from a non-rich-root repository to a rich-root
+ repository (e.g. from pack-0.92 to 2a) no longer fails with
+ ``'Inter1and2Helper' object has no attribute 'source_repo'``. This was
+ a regression from Bazaar 2.1. (Andrew Bennetts, #636930)
+
+Documentation
+*************
+
+* Added a builder/writer sphinx extension that can generate texinfo files. The
+ generated files are syntactically correct but the info navigation nodes
+ needs more work. (Vincent Ladeuil, #219334)
+
+* First tests defined for sphinx, including a new bzrlib.tests.features.sphinx
+ to make the tests conditional.
+ (Vincent Ladeuil)
+
+* Fix a lot of references in the docs to the old http://bazaar-vcs.org to
+ the new http://bazaar.canonical.com or http://wiki.bazaar.canonical.com
+ (John Arbash Meinel, #617503)
+
+API Changes
+***********
+
+* When passing a file to ``UTF8DirReader`` make sure to close the current
+ directory file handle after the chdir fails. Otherwise when passing many
+ filenames into a command line ``bzr status`` we would leak descriptors.
+ (John Arbash Meinel, #583486)
+
+* `ControlDirFormat` and `ControlDir` have been split out of `BzrDirFormat`
+ and `BzrDir`, respectively. `ControlDirFormat`
+ and `ControlDir` should be used as the base classes for new non-.bzr
+ implementations.
+
+ `BzrDirFormat.register_control_format` has been renamed to
+ `ControlDirFormat.register_format`.
+
+ `BzrDirFormat.register_server_control_format` has been removed.
+
+ Probing for control directories is now done by separate objects derived
+ from `bzrlib.controldir.Prober` and registered using
+ `bzrlib.controldir.ControlDirFormat.register_prober` or
+ `bzrlib.controldir.ControlDirFormat.register_server_prober`.
+ `BzrDirFormat.probe_transport` has been moved onto `Prober`.
+
+ `BzrDirFormat.register_format` has been renamed to
+ `BzrProber.register_bzrdir_format`.
+
+ `bzrlib.bzrdir.network_format_registry` has been moved to
+ `bzrlib.controldir`.
+
+ (Jelmer Vernooij)
+
+* ``bzrlib.transform.TreeTransformBase.final_kind``,
+ ``bzrlib.transform.TreeTransform.tree_kind`` and
+ ``bzrlib.transform.TransformPreview.tree_kind`` now return None instead
+ of raising NoSuchFile. (Vincent Ladeuil)
+
+* BzrError subclasses no longer support the name "message" to be used
+ as an argument for __init__ or in _fmt format specification as this
+ breaks in some Python versions. errors.LockError.__init__ argument
+ is now named "msg" instead of earlier "message".
+ (Parth Malwankar, #603461)
+
+* Configuration files should now use the ``from_string`` constructor rather
+ than the ``file`` parameter of the ``_get_parser`` method. The later has
+ been deprecated. ``from_string`` also accept a ``save=True`` parameter to
+ have the configuration file immediately written to disk.
+ (Vincent Ladeuil)
+
+* Deprecate treating a `PushResult` and `PullResult` as an integer for the
+ relative change in revno.
+ (Martin Pool)
+
+* `FileInWrongBranch` is deprecated in favour of `PathNotChild` and no
+ longer raised.
+ (Martin Pool)
+
+* ``IniBaseConfig`` objects should now use the ``from_string`` constructor
+ the rather than the ``file`` parameter of the ``_get_parser`` method. The
+ later has been deprecated. (Vincent Ladeuil)
+
+* InventoryEntry instances now raise AttributeError if you try to assign
+ to attributes that are irrelevant to that kind of entry. e.g. setting
+ ``symlink_target`` on an InventoryFile will fail. It is still okay to
+ read those attributes on any kind of InventoryEntry. The complete list
+ of affected attributes is: ``executable``, ``text_id``, ``text_sha1``,
+ ``text_size`` (only valid for kind == file); ``symlink_target`` (only
+ valid for kind == link); and ``reference_revision`` (only valid for kind
+ == tree-reference). (Andrew Bennetts)
+
+* InventoryEntry objects no longer have ``_put_in_tar`` or
+ ``_put_on_disk`` methods. (Andrew Bennetts)
+
+* The ``get_filename`` parameter in the ``config.IniBaseConfig``
+ constructor has been deprecated, use the ``file_name`` parameter instead.
+ (Vincent Ladeuil)
+
+* `tree_files` and `internal_tree_files` are now deprecated in favor of
+ `WorkingTree.open_containing_paths`.
+ (Martin Pool)
+
+Internals
+*********
+
+* Remove used and broken code path in ``BranchInitHookParams.__repr__``.
+ (Andrew Bennetts)
+
+Testing
+*******
+
+* Avoid spurious failures in ssh tests: wait for the SSH server to
+ actually finish, rather than just waiting for it to negotiate the key
+ exchange. (John Arbash Meinel, #626876)
+
+* ``build_tree_contents`` can create symlinks.
+ (Martin Pool, John Arbash Meinel)
+
+* Catch socket errors to avoid
+ bt.test_sftp_transport.SSHVendorBadConnection.test_bad_connection_ssh
+ random failures. (Vincent Ladeuil, #601804)
+
+* HTTP test servers will leak less threads (and sockets) and will not hang on
+ AIX anymore. (Vincent Ladeuil, #405745)
+
+* On platforms that don't support forking give a nice error message saying so
+ when ``bzr selftest --parallel=fork`` is used. (Martin [gz], #528730)
+
+* Rearrange thread leak detection code to eliminate global state and make it
+ possible to extend the reporting. (Martin [gz], #633462)
+
+* The old ``bzr selftest --benchmark`` option has been removed.
+ <https://launchpad.net/bzr-usertest> is an actively-maintained
+ macrobenchmark suite.
+ (Martin Pool)
+
+* The test suite now simply holds log files in memory, rather than writing them
+ out to disk and then reading them back in and deleting them.
+ (Andrew Bennetts)
+
+* The way ``bzr selftest --parallel`` generates N partitions of tests to
+ run in parallel has changed. Instead of splitting the list of tests at
+ N-1 points, it distributes the tests one-by-one into the partitions in a
+ round robin fashion. This reduces the total time to run the tests in
+ parallel because a series of slow tests in the test suite will be
+ distributed evenly among the parallel test suites, rather than slowing
+ down just one suite. (Andrew Bennetts)
+
+* Tracebacks from a parameterized test are no longer reported against every
+ parameterization of that test. This was done by adding a hack to
+ ``bzrlib.tests.clone_test`` so that it no longer causes
+ testtools.TestCase instances to share a details dict.
+ (Andrew Bennetts, #625574)
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-2.4.txt b/doc/en/release-notes/bzr-2.4.txt
new file mode 100644
index 0000000..776e79f
--- /dev/null
+++ b/doc/en/release-notes/bzr-2.4.txt
@@ -0,0 +1,1356 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 2.4.3
+#########
+
+:2.4.3: NOT RELEASED YET
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Cope with Unix filesystems, such as smbfs, where chmod gives 'permission
+ denied'. (Martin Pool, #606537)
+
+* When the ``limbo`` or ``pending-deletion`` directories exist, typically
+ because of an interrupted tree update, but are empty, bzr no longer
+ errors out, because there is nothing for the user to clean up. Also,
+ errors in creation of these directories are no longer squelched.
+ (Martin Pool, #427773)
+
+* During merges, when two entries end up using the same path for two
+ different file-ids (the same file being 'bzr added' in two different
+ branches) , 'duplicate' conflicts are created instead of 'content'
+ ones. This was previously leading to a 'Malformed tramsform' exception.
+ (Vincent Ladeuil, #880701)
+
+* 'Malformed transform' exceptions are now recognized as internal errors
+ instead of user errors and report a traceback. This will reduce user
+ confusion as there is generally nothing users can do about them.
+ (Vincent Ladeuil, #880701)
+
+* Prevent a traceback being printed to stderr when logging has problems and
+ accept utf-8 byte string without breaking. (Martin Packman, #714449)
+
+* _Win32Stat object provides members st_uid and st_gid, those are present
+ in Python's os.stat object. These members required for external tools like
+ bzr-git and dulwich. (Alexander Belchenko, #967060)
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+* Account for slightly improved compression with newer versions of zlib in
+ ``bt.test_btree_index`` tests. (Martin Packman, #940453)
+
+
+bzr 2.4.2
+#########
+
+:2.4.2: 2011-10-27
+
+This is a bugfix release. Most of the bugs dealt with portability
+issues. Upgrading is recommended for all users of earlier 2.4 releases.
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+New Features
+************
+
+None.
+
+Improvements
+************
+
+* Fixed a bug where ``bzr tags -r x..y`` loaded the branch history once for
+ every revision in the range; it's now much faster. (Vincent Ladeuil, #857335)
+
+Bug Fixes
+*********
+
+* Fixed an infinite loop when creating a repo at the root of the filesystem,
+ i.e. "/", due to posixpath.normpath() not collapsing 2 leading slashes into
+ one, thus respecting the POSIX standard, but making relpath() loop infinitely.
+ (Florian Vichot, #861008)
+
+* Fixed loading of external merge tools from config to properly decode
+ command-lines which contain embedded quotes. (Gordon Tyler, #828803)
+
+* Include declaration of 'changed' to avoid an UnboundLocalError in dirstate
+ pyrex code with new Cython versions. (Denys Duchier, #837221)
+
+* Prevent several kinds of OverflowError and other fallout from failing to fit
+ stat fields into four bytes in dirstate pack_stat implementations.
+ (Martin Packman, #683191 #706957)
+
+* Return early from create_delta_index_from_delta given tiny inputs. This
+ avoids raising a spurious MemoryError on certain platforms such as AIX.
+ (John Arbash Meinel, #856731)
+
+Documentation
+*************
+
+* Corrected documentation for ``bzr serve`` in the Admin Guide.
+ (Morten Bøgeskov, Martin Pool, #832576)
+
+API Changes
+***********
+
+None.
+
+Internals
+*********
+
+No changes.
+
+Testing
+*******
+
+* Accept both old and new style testtools output in selftest tests.
+ (Jelmer Vernooij, Martin Packman, #815423)
+
+* Fix the race for TestingThreadingTCPServer in
+ test_server_crash_while_responding. (Vincent Ladeuil, #869366)
+
+* Really corrupt the pack file without depending on a special length or value.
+ (Vincent Ladeuil, #807032)
+
+
+bzr 2.4.1
+#########
+
+:2.4.1: 2011-09-08
+
+This is a bugfix release. Upgrading is recommended for all users of earlier
+2.4 releases.
+
+It includes fixes from previous stable releases and address some issues with
+the test suite.
+
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* ``config.LocationMatcher`` properly excludes unrelated sections.
+ (Vincent Ladeuil, #829237)
+
+* ``dirstate.fdatasync`` and ``repository.fdatasync`` can now properly be
+ disabled. (Vincent Ladeuil, #824513)
+
+* Disable ``os.fsync`` and ``os.fdatasync`` by default when running
+ ``bzr selftest``. You can use ``--sync`` to re-enable them.
+ (John Arbash Meinel, #837293)
+
+* Fix i18n use when no environment variables are set. (Jelmer Vernooij, #810701)
+
+* Avoid UnicodeDecode error when reporting EINVAL from transports.
+ (IWATA Hidetaka, #829237)
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+* Corrected documentation for BZR_PROGRESS_BAR.
+ (Dennis Benzinger, #735417)
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+* The test suite should now be able to run under weird environments where
+ ``/etc/passwd`` doesn't contain the ``uid`` for the user running selftest
+ or where ``fakeroot`` is used but ``/root`` is inacessible.
+ (Vincent Ladeuil, #825027)
+
+bzr 2.4.0
+#########
+
+:2.4.0: 2011-08-11
+
+This release marks the start of a new long-term-stable series. From here, we
+will only make bugfix releases on the 2.4 series (2.4.1, etc, and support it
+until February 2013), while 2.5 will become our new development series.
+
+This is a bugfix and polish release over the 2.3 series, with a large number
+of bugs fixed (>150 for the 2.4 series alone), and some performance
+improvements. Support for python 2.4 and 2.5 has been dropped, many large
+working tree operations have been optimized as well as some stacked branches
+operations.
+
+Only bugfixes from other stables series have been included since 2.4b5 so
+all known fixed bugs are included here.
+
+Users are encouraged to upgrade from the other stable series.
+
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* A call to CHKInventory's filter-method will not result in a
+ DuplicateFileId error, if you move a subfolder and change a file in
+ that subfolder.
+ (Bastian Bowe, #809901)
+
+* Accessing a packaging branch on Launchpad (eg, ``lp:ubuntu/bzr``) now
+ checks to see if the most recent published source package version for
+ that project is present in the branch tags. This should help developers
+ trust whether the packaging branch is up-to-date and can be used for new
+ changes. The level of verbosity is controlled by the config item
+ ``launchpad.packaging_verbosity``. It can be set to one of
+
+ off
+ disable all checks
+
+
+ minimal
+ only display if the branch is out-of-date
+
+ short
+ also display single-line up-to-date and missing,
+
+
+ all
+ (default) display multi-line content for all states
+
+
+ (John Arbash Meinel, #609187, #812928)
+
+* Cope with not all Python versions having a ``clear`` method on
+ ``TestCase._type_equality_funcs``.
+ (Martin [gz], Jelmer Vernooij, #809048)
+
+* Fetching tags when fetching the tip revision of a branch is now
+ controlled by the config setting ``branch.fetch_tags``. The behavior has
+ been reverted to 2.3's not-fetching tagged revisions by default.
+ (John Arbash Meinel, #771184)
+
+* The fix for bug #513709 caused us to open a new connection when
+ switching a lightweight checkout that was pointing at a bound branch.
+ This isn't necessary because we know the master URL without opening it,
+ avoiding an extra SSH connection, etc.
+ (John Arbash Meinel, #812285)
+
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+* `BranchBuilder.build_snapshot` now supports a "flush" action. This
+ cleanly and reliably allows tests using `BranchBuilder` to construct
+ branches that e.g. rename files out of a directory and unversion that
+ directory in the same revision. Previously some changes were impossible
+ due to the order that `build_snapshot` performs its actions.
+ (Andrew Bennetts)
+
+* `TestCaseWithMemoryTransport` is faster now: `_check_safety_net` now
+ just compares the bytes in the dirstate file to its pristine state,
+ rather than opening the WorkingTree and calling ``last_revision()``.
+ This reduces the overall test suite time by about 10% on my laptop.
+ (Andrew Bennetts)
+
+
+bzr 2.4b5
+#########
+
+:2.4b5: 2011-07-07
+
+This is the fifth (and last) beta of the 2.4 series leading to
+2.4.0 release in August 2011. Beta releases are suitable for
+everyday use but may cause some incompatibilities with plugins.
+
+This release includes all bug fixed in previous series known at
+the time of this release.
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+New Features
+************
+
+* New command ``verify-signatures`` to check if all commits or specified commits
+ have digital signatures from trusted keys. Requires python-gpgme to be
+ installed.
+
+* New option ``--signatures`` for ``bzr log`` to display digital signature
+ verification results for each commit.
+
+* Config option acceptable_keys to list which GPG keys are verified as trusted.
+
+* Config option validate_signatures_in_log to always show signatures in
+ ``bzr log``.
+
+Improvements
+************
+
+* ``Branch.open`` is now about 3x faster (about 2ms instead of 6.5ms).
+ (Andrew Bennetts).
+
+* Pack, dirstate, and index files are synced to persistent storage if
+ possible when writing finishes, to reduce the risk of problems caused by
+ a machine crash or similar problem. This can be turned off through the
+ ``dirstate.fdatasync`` and ``repository.fdatasync`` options, which can
+ be set in ``locations.conf`` or ``bazaar.conf``. (Martin Pool,
+ #343427)
+
+Bug Fixes
+*********
+
+* Display a proper error message when a config file content cannot be
+ decoded as UTF-8 or when it cannot be parsed.
+ (Vincent Ladeuil, #502060, #688677, #797246)
+
+* Generate a single conflict (instead of two) when merging a branch
+ modifying and renaming a file in a branch that deleted it (or vice-versa).
+ (Vincent Ladeuil, #688101)
+
+* Give a more helpful message when the bzr executable doesn't match the
+ library. (This typically happens because of a misconfigured PYTHONPATH
+ or half-installed bzr.)
+ (Martin Pool, #804553)
+
+* Properly load utf8-encoded config files. (Vincent Ladeuil, #799212)
+
+* ``GraphThunkIdsToKeys.merge_sort`` now properly returns
+ keys rather than ids. (Jelmer Vernooij, #799677)
+
+* ``TreeTransformBase.fixup_new_roots`` can now check that a tree root
+ is present. (Jelmer Vernooij, #801257)
+
+API Changes
+***********
+
+* New attributes ``WorkingTreeFormat.supports_versioned_directories`` and
+ ``RepositoryFormat.supports_versioned_directories``.
+ (Jelmer Vernooij, #765815)
+
+* The "revno" field type when using the python version-info format is now
+ a string (to handle dotted revnos) (Benoît Pierre, #796259)
+
+Internals
+*********
+
+* Start implementing localization, starting with command help text (but not
+ the command options themselves). This will allow bootstrapping the bzr
+ internationalization process. (Inada Naoki)
+
+Testing
+*******
+
+* Fix test failures when running as a homeless user (debian buildd). Tests
+ leaking into ``${HOME}/.bzr.log`` should be detected properly now.
+ (Vincent Ladeuil, #798698)
+
+bzr 2.4b4
+#########
+
+:2.4b4: 2011-06-16
+
+This is the fourth beta of the 2.4 series, leading to a 2.4.0 release in
+August 2011. Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins.
+
+This release includes all bug fixed in previous series known at the time of
+this release.
+
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+* Do not treat configuration option 'check_signatures = require' as if
+ it were 'create_signatures = always' (Jonathan Riddell)
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+* Hooks have been added for config stacks: ``get``, ``set`` and ``remove``
+ are called when an option is respectively read, modified or deleted. Also
+ added ``load`` and ``save`` hooks for config stores, called when the
+ stores are loaded or saved. (Vincent Ladeuil)
+
+* New hook server_exception in bzrlib.smart.server to catch any
+ exception caused while running bzr serve.
+ (Jonathan Riddell, #274578)
+
+* New hook set_commit_message in bzrlib.msgeditor to set a commit message
+ and revision properties. (Jonathan Riddell, #274578)
+
+* Support ``-S`` as an alias for ``--short`` for the ``log`` and
+ ``missing`` commands. (Martin von Gagern, #38655)
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+* ``bzr annotate`` can be run without setting whoami data first.
+ (Jonathan Riddell, #667408)
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Bazaar can now detect when a lock file is held by a dead process
+ originating from the same machine, and steal the lock after printing a
+ message to the user. This is off by default, for safety, but can be
+ turned on by setting the configuration variable ``locks.steal_dead`` to
+ ``True``.
+ (Martin Pool, #220464)
+
+* ``bzr version-info`` now works when the tree is on a dotted revno.
+ (Benoît Pierre, #796259)
+
+* Credentials in the log output produced by ``-Dhttp`` are masked so users
+ can more freely post them in bug reports. (Vincent Ladeuil, #723074)
+
+* Fix a race condition for ``server_started`` hooks leading to a spurious
+ test failure. (Vincent Ladeuil, #789167)
+
+* Fix exporting subdirectory with ``--per-file-timestamps``.
+ (Szilveszter Farkas, #795557)
+
+* Handle files that get created but don't get used during TreeTransform.
+ ``open()`` can create a file, and still raise an exception before it
+ returns. So anything we might have created, make sure we destroy during
+ ``finalize()``. (Martin [gz], #597686)
+
+* ``pack_repo`` now uses ``Transport.move`` instead of
+ ``Transport.rename``, deleting any existing targets even on SFTP.
+ (Martin von Gagern, #421776)
+
+* Pass the ``build_mo`` command to the rest of the setup() calls in
+ setup.py. The ``bdist_wininst`` and ``py2exe`` code paths were failing
+ because ``build_mo`` became a required step that they didn't know about.
+ (John Arbash Meinel, #787122)
+
+* Preserve existing ``root-id`` when merging an unrelated branch.
+ (Aaron Bentley, #806356)
+
+* Properly avoid re-adding a file after it changes case on CICP
+ filesystems. (John Arbash Meinel, #798130)
+
+* Reports the original error when an InvalidHttpResponse exception is
+ encountered to facilitate debug. (Vincent Ladeuil, #788530)
+
+* Reports a non-existent file error when trying to merge in a file
+ that does not exist. (Jonathan Riddell, #330063)
+
+* ``UIFactory.prompt``, ``UIFactory.get_username``,
+ ``UIFactory.get_password`` and ``UIFactory.get_boolean`` now require a
+ unicode prompt to be passed in. (Jelmer Vernooij, #592083)
+
+* Support merging into the empty tree. (Aaron Bentley, #595328)
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+* Improve documentation of ``bzr merge --force``.
+ (Neil Martinsen-Burrell, #767307)
+
+* Make docs for configuration options for digital signatures match
+ reality. (Jonathan Riddell)
+
+* Add user-guide page on GPG signatures. (Jonathan Riddell)
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+* Checking for a file id in a `Tree` or `Inventory` using ``in`` is now
+ deprecated. Instead, use `has_id`.
+ (Martin Pool)
+
+* Exporters are now all exposed as generators, rather than as single-call
+ functions, so that calling code can take stream the output.
+ (Xaav, Martin Pool)
+
+* Information about held lockdir locks returned from eg `LockDir.peek` is
+ now represented as a `LockHeldInfo` object, rather than a plain
+ Python dict.
+ (Martin Pool)
+
+* Remove `file_status` function.
+ (Martin Pool)
+
+* ``Repository.iter_reverse_revision_history`` is now deprecated.
+ Use ``Graph.iter_lefthand_ancestry`` instead.
+ (Jelmer Vernooij, #739481)
+
+* ``Repository.get_ancestry`` has been deprecated. Use
+ ``Graph.iter_ancestry`` instead.
+ (Jelmer Vernooij, #784511)
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+* ``tools/check-newsbugs.py`` accepts a ``--browser`` option to open
+ corresponding launchpad pages in a browser. (Vincent Ladeuil)
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+* A `ImportTariffTestCase` base class has been added in
+ ``bzrlib.tests.test_import_tariff``, which can be used for import tariff
+ tests in plugins. (Jelmer Vernooij, #793465)
+
+* Fix deadlock in `TestImportTariffs.test_simple_serve` when stderr gets
+ more output than fits in the default buffer. This was happening on the
+ Windows buildslave, and could easily happen in other circumstances where
+ the default OS buffer size for pipes is small or the ``python -v``
+ output is large. (Andrew Bennetts, #784802)
+
+* Fix spurious test failure on OSX for WorkingTreeFormat2.
+ (Vincent Ladeuil, #787942)
+
+* Re-target ``bb.test_merge.TestMerge.test_merge_reversed_revision_range``
+ and rewrite it as a parametrized test to avoid unrelated failures.
+ (Vincent Ladeuil, #795456)
+
+* Show log file contents from subprocesses started by
+ `start_bzr_subprocess` in test failure details. This may help diagnose
+ strange hangs and failures involving subprocesses. (Andrew Bennetts)
+
+* Skip ``utextwrap`` tests when ``sphinx`` breaks text_wrap by an hostile
+ monkey-patch to textwrap.TextWrapper.wordsep_re.
+ (Vincent Ladeuil, #785098)
+
+* Multiple ``selftest --exclude`` options are now combined instead of
+ overriding each other. (Vincent Ladeuil, #746991)
+
+* Restore some ``FTPTransport`` test coverage by allowing ``pyftpdlib
+ 0.6.0`` to be used. Also restore ``medusa`` support while leaving it
+ disabled to make it easier to use if/when we can in the future.
+ (Vincent Ladeuil, #781140)
+
+* `TestImportTariffs` no longer uses the real ``$HOME``. This prevents it
+ from polluting ``$HOME/.bzr.log`` or being accidentally influenced by
+ user configuration such as aliases. It still runs with all the user's
+ plugins enabled, as intended.
+ (Vincent Ladeuil, Andrew Bennetts, #789505)
+
+
+bzr 2.4b3
+#########
+
+:2.4b3: 2011-05-26
+
+This is the third beta of the 2.4 series, leading to a 2.4.0 release in
+August 2011. Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins.
+
+This release includes all bug fixed in previous series known at the time of
+this release.
+
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+* ``bzr-2.4`` has officially dropped support for python2.4 and python2.5.
+ We will continue to maintain ``bzr-2.3`` for people who still need to
+ use those versions of python. (John Arbash Meinel)
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+* The text compressor used for 2a repositories now has a tweakable
+ parameter that can be set in bazaar.conf.
+ ``bzr.groupcompress.max_entries_per_source`` default of 65536.
+ When doing compression, we build up an index of locations to match
+ against. Setting this higher will result in slightly better compression,
+ at a cost of more memory. Note that a value of 65k represents fully
+ sampling a 1MB file. So this only has an effect when compressing texts
+ larger than N*16 bytes. (John Arbash Meinel, #602614)
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+* ``bzr branch --stacked`` from a smart server uses the network a little
+ more efficiently. For a simple branch it reduces the number of
+ round-trips by about 20%. (Andrew Bennetts)
+
+* ``bzr log --line`` scales the width of the author field with the size of
+ the line. This means that the full author name is shown when the
+ environment variable BZR_COLUMNS=0. (Neil Martinsen-Burrell)
+
+* ``bzr pull`` now properly triggers the fast
+ ``CHKInventory.iter_changes`` rather than the slow generic
+ inter-Inventory changes. It used to use a ``DirStateRevisionTree`` as
+ one of the source trees, which is faster when we have to read the whole
+ inventory anyway, but much slower when we can get just the delta out of
+ the repository. On a 70k record tree, this changes ``bzr pull`` from 28s
+ down to 17s. (John Arbash Meinel, #780677)
+
+* Slightly reduced memory consumption when fetching into a 2a repository
+ by reusing existing caching a little better. (Andrew Bennetts)
+
+* Speed up ``bzr status`` by a little bit when there are a couple of
+ modified files. We now track how many files we have seen that need
+ updating, and only rewrite the dirstate file if enough of them have
+ changed. The default is 10, and can be overridden by setting the branch
+ option "``bzr.workingtree.worth_saving_limit``".
+ (Ian Clatworthy, John Arbash Meinel, #380202)
+
+* Speed up ``bzr uncommit``. Instead of resetting the dirstate from
+ scratch, use ``update_basis_by_delta``, computing the delta from the
+ repository. (John Arbash Meinel, #780544)
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* All Tree types can now be exported as tar.*, zip or directories.
+ (Aaron Bentley)
+
+* ``bzr merge --no-remember location`` never sets ``submit_branch``.
+ (Vincent Ladeuil, #782169)
+
+* ``bzr pull --no-remember location`` never sets
+ ``parent_location``. ``bzr push --no-remember location`` never
+ sets ``push_location``. ``bzr send --no-remember
+ submit_location public_location`` never sets ``submit_branch``
+ nor ``public_branch``. (Vincent Ladeuil)
+
+* Conflicts involving non-ascii filenames are now properly reported rather
+ than failing with a UnicodeEncodeError. (Martin [GZ], #686161)
+
+* Correct parent is now set when using 'switch -b' with bound branches.
+ (A. S. Budden, #513709)
+
+* Fix `bzr plugins` regression in bzr 2.4 which resulted in a traceback
+ from writelines on ckj terminals. (Martin [GZ], #754082)
+
+* ``WT.inventory`` and ``WT.iter_entries_by_dir()`` was not correctly
+ reporting subdirectories that were tree references (in formats that
+ supported them). (John Arbash Meinel, #764677)
+
+* Merging into empty branches now gives an error as this is currently
+ not supported. (Jonathan Riddell, #242175)
+
+* Do not show exception to user on pointless commit error.
+ (Jonathan Riddell #317357)
+
+* ``WT.update_basis_by_delta`` no longer requires that the deltas match
+ the current WT state. This allows ``update_basis_by_delta`` to be used
+ by more commands than just commit. Updating with a delta allows us to
+ not load the whole inventory, which can take 10+s with large trees.
+ (Jonathan Riddell, John Arbash Meinel, #781168)
+
+* ``bzr mv --after old_name new_name`` now works if "new_name" is newly
+ added. (Benoît Pierre)
+
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+* Restore the workaround for option names including dots (--1.14) which was
+ disabled when we stopped listing --1.9 as a format.
+ (Vincent Ladeuil, #782289)
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+* ``annotate_file`` has been deprecated in favor of
+ ``annotate_file_revision_tree``. (Jelmer Vernooij, #775598)
+
+* ``Branch.fetch`` now takes an optional ``limit`` argument.
+ (Andrew Bennetts, Jelmer Vernooij, #750175)
+
+* ``Inter.get`` now raises ``NoCompatibleInter`` if there are no
+ compatible optimisers rather than an instance of the class it is called
+ on. (Jelmer Vernooij)
+
+* ``Branch.push`` now takes a ``lossy`` argument.
+ ``Branch.lossy_push`` has been removed.
+ (Jelmer Vernooij)
+
+* New method ``Repository.get_file_graph`` which can return the
+ per-file revision graph. (Jelmer Vernooij, #775578)
+
+* The default implementation of ``Branch`` is now oriented to
+ storing the branch tip. Branch implementations which store the full
+ history should now subclass ``FullHistoryBzrBranch``.
+ ``Branch._last_revision_info`` has been renamed to
+ ``Branch._read_last_revision_info`` (Jelmer Vernooij)
+
+* ``Tree.__iter__`` has been deprecated; use ``Tree.all_file_ids``
+ instead. (Jelmer Vernooij)
+
+* ``Tree.get_symlink_target`` now takes an optional ``path``
+ argument. (Jelmer Vernooij)
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+* ``MutableTree.smart_add`` now uses inventory deltas.
+ (Jelmer Vernooij, #146165)
+
+* Removed ``bzrlib.branch._run_with_write_locked_target`` as
+ ``bzrlib.cleanup`` provides the same functionality in a more general
+ way. (Andrew Bennetts)
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+* A test that was expected to fail but passes instead now counts as a failure
+ catching up with new testtools and subunit handling. (Martin [GZ], #654474)
+
+* Make it easier for plugins to reuse the per_workingtree scenarios by
+ restoring the wt_scenarios helper that was accidentally deleted.
+ (Vincent Ladeuil, #783472)
+
+* Removed ``test_breakin`` tests that were excessively prone to hanging,
+ did not work on Wine, and partly already disabled.
+ (Martin Pool, #408814, #746985)
+
+* Windows locations are different and should be tested accordingly.
+ (Vincent Ladeuil, #788131)
+
+bzr 2.4b2
+#########
+
+:2.4b2: 2011-04-28
+
+This is the second beta of the 2.4 series, leading to a 2.4.0 release in
+August 2011. Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins.
+
+This release includes all bug fixed in previous series known at the time of
+this release.
+
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+* Two command synonyms for ``bzr branch`` have been deprecated, to avoid
+ confusion and to allow the names to later be reused. The removed names
+ are: ``get`` and ``clone``. (Martin Pool, #506265)
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+* ``bzr commit`` now supports a ``--lossy`` argument that can be used
+ to discard any data that can not be natively represented when committing
+ to a foreign VCS. (Jelmer Vernooij, #587721)
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+* ``bzr merge`` in large trees is now significantly faster. On a 70k entry
+ tree, the time went from ~3min down to 30s. This also effects ``bzr pull``
+ and ``bzr update`` since they use the same merge logic to update the
+ WorkingTree. (John Arbash Meinel, #759091)
+
+* ``bzr revert`` now properly uses ``bzr status``'s optimized
+ ``iter_changes``. This can be a significant performance difference (33s
+ to 5s on large trees). (John Arbash Meinel, #759096)
+
+* Resolve ``lp:FOO`` urls locally rather than doing an XMLRPC request if
+ the user has done ``bzr launchpad-login``. The bzr+ssh URLs were already
+ being handed off to the remote server anyway (xmlrpc has been mapping
+ ``lp:bzr`` to ``bzr+ssh://bazaar.launchpad.net/+branch/bzr``, rather
+ than ``bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev`` for a few
+ months now.) By doing it ourselves, we can cut out substantial startup
+ time. From Netherlands to London it was taking 368ms to do the XMLRPC
+ call as much as 2s from Sydney. You can test the local logic by using
+ ``-Dlaunchpad``. (John Arbash Meinel, #397739)
+
+* When building a new WorkingTree (such as during ``bzr co`` or
+ ``bzr branch``) we now properly store the stat and hash of files that
+ are old enough. This saves a fair amount of time on the first
+ ``bzr status`` (on a 500MB tree, it saves about 30+s).
+ (John Arbash Meinel, #740932)
+
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Arguments that can't be decoded to unicode in the current posix locale give
+ a clearer error message without a traceback. (Martin [gz], #745712)
+
+* ``bzrlib.log._DEFAULT_REQUEST_PARAMS`` is no longer accidentally
+ mutated by ``bzrlib.log._apply_log_request_defaults``. In practice
+ these default values aren't relied on very often so this probably
+ wasn't causing any trouble. (Andrew Bennetts)
+
+* ``bzr log`` now works on revisions which are not in the current branch.
+ (Matt Giuca, #241998)
+
+* Don't rewrite the dirstate file when non-interesting changes have
+ occurred. This can significantly improve 'bzr status' times when there
+ are only small changes to a large tree.
+ (Ian Clatworthy, John Arbash Meinel, #380202)
+
+* Lazy hooks are now reset between test runs. (Jelmer Vernooij, #745566)
+
+* ``bzrlib.merge.Merge`` now calls ``iter_changes`` without
+ ``include_unversioned=True``. This makes it significantly faster in many
+ cases, because it only looks at modified files, rather than building
+ information about all files. This can cause failures in other
+ TreeTransform code, because it had been expecting to know the names of
+ things which had not changed (such as parent directories). All cases we
+ know about so far have been fixed, but there may be fallout for edge
+ cases that we are missing. (John Arbash Meinel, #759091)
+
+* ``SFTPTransport`` is more pro-active about closing file-handles. This
+ reduces the chance of having threads fail from async requests while
+ running the test suite. (John Arbash Meinel, #656170)
+
+* Standalone bzr.exe installation on Windows: user can put additional python
+ libraries into ``site-packages`` subdirectory of the installation directory,
+ this might be required for "installing" extra dependencies for some plugins.
+ (Alexander Belchenko, #743256)
+
+* ``transform.revert()`` has been updated to use
+ ``wt.iter_changes(basis_tree)`` rather than
+ ``basis_tree.iter_changes(wt)``. This allows the optimized code path to
+ kick in, improving ``bzr revert`` times significantly (33s to 4s on
+ large trees, 0.7s to 0.3s on small trees.) (John Arbash Meinel, #759096)
+
+* ``TreeTransform.create_file/new_file`` can now take an optional ``sha1``
+ parameter. If supplied, when the transform is applied, it will then call
+ ``self._tree._observed_sha1`` for those files. This lets us update the
+ hash-cache for content that we create, preventing us from re-reading the
+ content in the next ``bzr status``. (John Arbash Meinel, #740932)
+
+Documentation
+*************
+
+* Added a section about using a shared SSH account on a server for bzr+ssh
+ access. (Russell Smith)
+
+* The documentation now recommends using SSH rather than SFTP in the
+ tutorials and the examples, because that will generally be much faster
+ and better in cases where it can be used. SFTP is still available and
+ mentioned as an alternative. (Martin Pool, #636712)
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+* ``Branch.update_revisions`` has been made private and should no
+ longer be used by external users. Use ``Branch.pull`` or ``Branch.push``
+ instead. (Jelmer Vernooij, #771765)
+
+* Commands now have an `invoked_as` attribute, showing the name under
+ which they were called before alias expansion.
+ (Martin Pool)
+
+* ``Hooks.create_hook`` is now deprecated in favour of ``Hooks.add_hook``.
+ (Jelmer Vernooij)
+
+* If you call `bzrlib.initialize` but forget to enter the resulting object
+ as a context manager, bzrlib will now be initialized anyhow.
+ (Previously simple programs calling bzrlib might find the library was
+ mysteriously silent.)
+ (Martin Pool)
+
+* Inventory-specific functionality has been split out of ``Tree`` into
+ a new ``InventoryTree`` class. Tree instances no longer
+ necessarily provide an ``inventory`` attribute. (Jelmer Vernooij)
+
+* Inventory-specific functionality has been split out of ``RevisionTree``
+ into a new ``InventoryRevisionTree`` class. RevisionTree instances no
+ longer necessarily provide an ``inventory`` attribute. (Jelmer Vernooij)
+
+* New method ``Hooks.uninstall_named_hook``. (Jelmer Vernooij, #301472)
+
+* ``revision_graph_can_have_wrong_parents`` is now an attribute
+ on ``RepositoryFormat`` rather than a method on ``Repository``.
+ (Jelmer Vernooij)
+
+* ``Testament`` now takes a ``tree`` rather than an
+ ``inventory``. (Jelmer Vernooij, #762608)
+
+* ``TestCase.failUnlessExists`` and ``failIfExists`` are deprecated in
+ favour of ``assertPathExists`` and ``assertPathDoesNotExist``
+ respectively.
+ (Martin Pool)
+
+* The ``revno`` parameter of ``log.LogRevision`` may now be None,
+ representing a revision which is not in the current branch.
+ (Matt Giuca, #241998)
+
+* The various knit pack repository format classes have been moved
+ from ``bzrlib.repofmt.pack_repo`` to
+ ``bzrlib.repofmt.knitpack_repo``. (Jelmer Vernooij)
+
+* ``RevisionTree`` now has a new method ``get_file_revision``.
+ (Jelmer Vernooij)
+
+* ``WorkingTree`` no longer provides an ``inventory``. Instead,
+ all inventory-related functionality is now on the subclass
+ ``InventoryWorkingTree`` that all native Bazaar working tree
+ implementations derive from. (Jelmer Vernooij)
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+* Added ``osutils.lstat`` and ``osutils.fstat``. These are just the ``os``
+ functions on Linux, but they are wrapped on Windows so that fstat
+ matches lstat results across all python versions.
+ (John Arbash Meinel)
+
+* ``WorkingTree._observed_sha1`` also updates the 'size' column. It
+ happened to be updated as a side-effect of commit, but if we start using
+ the function elsewhere we might as well do it directly.
+ (John Arbash Meinel)
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+* Stop using `failIf`, `failUnless`, `failIfEqual`, etc, that give
+ `PendingDeprecationWarnings` on Python2.7.
+ (Martin Pool, #760435)
+
+
+bzr 2.4b1
+#########
+
+:2.4b1: 2011-03-17
+
+This is the first beta of the 2.4 series, leading up to a 2.4.0
+release in August 2011. Beta releases are suitable for everyday use
+but may cause some incompatibilities with plugins. Some plugins may need
+small updates to work with 2.4b1.
+
+External Compatibility Breaks
+*****************************
+
+(none)
+
+New Features
+************
+
+* Added ``changelog_merge`` plugin for merging changes to ``Changelog`` files
+ in GNU format. See ``bzr help changelog_merge`` for details.
+ (Andrew Bennetts)
+
+* Configuration options can now use references to other options in the same
+ file by enclosing them with curly brackets (``{other_opt}``). This makes it
+ possible to use, for example,
+ ``push_location=lp:~vila/bzr/config-{nickname}`` in ``branch.conf`` when
+ using a loom. During the beta period, the default behaviour is to disable
+ this feature. It can be activated by declaring ``bzr.config.expand = True``
+ in ``bazaar.conf``. (Vincent Ladeuil)
+
+* External merge tools can now be configured in bazaar.conf. See
+ ``bzr help configuration`` for more information. (Gordon Tyler, #489915)
+
+* The ``lp:`` directory service now supports Launchpad's QA staging.
+ (Jelmer Vernooij, #667483)
+
+Improvements
+************
+
+* A new hidden command ``bzr repair-workingtree``. This is a way to force
+ the dirstate file to be rebuilt, rather than using a ``bzr checkout``
+ workaround. (John Arbash Meinel)
+
+* Added a ``Branch.heads_to_fetch`` RPC to the smart server protocol.
+ This allows formats from plugins (such as looms) to efficiently tell the
+ client which revisions need to be fetched. (Andrew Bennetts)
+
+* Branching, merging and pulling a branch now copies revisions named in
+ tags, not just the tag metadata. (Andrew Bennetts, #309682)
+
+* ``bzr cat-revision`` no longer requires a working tree.
+ (Jelmer Vernooij, #704405)
+
+* ``bzr export --per-file-timestamps`` for .tar.gz files will now
+ override the mtime for trees exported on Python 2.7 and later, which
+ expose the 'mtime' field in gzip files. This makes the output of
+ ``bzr export --per-file-timestamps`` for a particular tree
+ deterministic. (Jelmer Vernooij, #711226)
+
+* ``bzr export --format=zip`` can now export to standard output,
+ like the other exporters can. (Jelmer Vernooij, #513752)
+
+* ``bzr export`` can now create ``.tar.xz`` and ``.tar.lzma`` files.
+ (Jelmer Vernooij, #551714)
+
+* Getting all entries from ``CHKInventory.iter_entries_by_dir()`` has been
+ sped up dramatically for large trees. Iterating by dir is not the best
+ way to load data from a CHK inventory, so it preloads all the items in
+ the correct order. (With the gcc-tree, this changes it (re)reading 8GB
+ of CHK data, down to just 150MB.) This has noticeable affects for things
+ like building checkouts, etc. (John Arbash Meinel, #737234)
+
+Bug Fixes
+*********
+
+* A MemoryError thrown on the server during a remote operation will now be
+ usefully reported, and other unexpected errors will include the class name.
+ (Martin [gz], #722416)
+
+* ``bzr annotate -r-1 file`` will now properly annotate a deleted file.
+ (Andrew King, #537442)
+
+* ``bzr export`` to zip files will now set a mode on directories.
+ (Jelmer Vernooij, #207253)
+
+* ``bzr export`` to tgz files will only write out the basename of the
+ tarfile to the gzip file. (Jelmer Vernooij, #102234)
+
+* ``bzr push --overwrite`` with an older revision specified will now correctly
+ roll back the target branch. (Jelmer Vernooij, #386576)
+
+* ``bzr lp-propose`` can now propose merges against packaging branches on
+ Launchpad without requiring the target branch to be specified.
+ (Jelmer Vernooij, #704647)
+
+* ``bzr lp-propose`` no longer requires a reviewer to be specified. It will
+ instead leave setting the reviewer up to Launchpad if it was not specified.
+ (Jelmer Vernooij, #583772)
+
+* ``bzr pull`` will now exit with exit code 1 if there were tag conflicts.
+ (Jelmer Vernooij, #213185)
+
+* ``bzr mv`` user errors no longer throw UnicodeEncodeError with non-ascii
+ paths, however they may still print junk if not on a UTF-8 terminal.
+ (Martin [gz], #707954)
+
+* ``bzr reconfigure --unstacked`` now copies revisions (and their
+ ancestors) named in tags into the unstacked repository, not just the
+ ancestry of the branch's tip. (Andrew Bennetts, #401646)
+
+* ``bzr serve`` no longer crashes when a server_started hook is installed and
+ IPv6 support is available on the system. (Jelmer Vernooij, #293697)
+
+* ``bzr status`` will not rewrite the dirstate file if it only has
+ 'trivial' changes. (Currently limited to dir updates and newly-added
+ files changing state.) This saves a bit of time for regular operations.
+ eg. ``bzr status`` in a 100k tree takes 1.4s to compute the status, but 1s
+ to re-save the dirstate file. (John Arbash Meinel, #765881)
+
+* ``bzr tags`` will no longer choke on branches with ghost revisions in
+ their mainline and tags on revisions not in the branch ancestry.
+ (Jelmer Vernooij, #397556)
+
+* ``bzr whoami`` will now display an error if both a new identity and
+ ``--email`` were specified. (Jelmer Vernooij, #680449)
+
+* ``launchpadlib`` doesn't provide the ``uris`` module in some old versions.
+ (Vincent Ladeuil, #706835)
+
+* Empty entries in the ``NO_PROXY`` variable are no longer treated as matching
+ every host.
+ (Martin Pool, #586341)
+
+* Plugins incompatible with the current version of bzr no longer produce a
+ warning on every command invocation. Instead, a message is shown by
+ ``bzr plugins`` and in crash reports.
+ (#704195, Martin Pool)
+
+* The "pretty" version of ``needs_read_lock`` and ``needs_write_lock`` now
+ preserves the identity of default parameter values.
+ (Andrew Bennetts, #718569)
+
+* ``bzr dump-btree --raw`` no longer tracebacks on a B-Tree file
+ containing no rows. (Eric Siegerman, #715508)
+
+* Fix ``bzr lp-mirror`` to work on command line branch URLs and branches
+ without an explicit public location. (Max Bowsher)
+
+* On Python 2.6 and higher, use multiprocessing.cpu_count() to retrieve the
+ number of available processors. (Jelmer Vernooij, #693140)
+
+API Changes
+***********
+
+* Added ``Branch.heads_to_fetch`` method. Implementations of the Branch API
+ must now inherit or implement this method. (Andrew Bennetts, #721328)
+
+* Added ``bzrlib.mergetools`` module with helper functions for working with
+ the list of external merge tools. (Gordon Tyler, #489915)
+
+* All methods and arguments that were deprecated before 2.0
+ have been removed. (Jelmer Vernooij)
+
+* Branch formats should now be registered on the format registry
+ (``bzrlib.branch.format_registry``) rather than using the class
+ methods on ``BranchFormat``. (Jelmer Vernooij, #714729)
+
+* ``Branch.set_revision_history`` is now deprecated.
+ (Jelmer Vernooij)
+
+* ``BranchFormat.supports_leaving_lock()`` and
+ ``RepositoryFormat.supports_leaving_lock`` flags have been added.
+ (Jelmer Vernooij)
+
+* ``Branch.fetch`` implementations must now accept an optional
+ ``fetch_tags`` keyword argument. (Andrew Bennetts)
+
+* ``Branch.import_last_revision_info`` is deprecated. Use the
+ ``import_last_revision_info_and_tags`` method instead.
+ (Andrew Bennetts)
+
+* Because it was too specific to BzrDir implementations,
+ ``ControlDir.sprout`` no longer has a default implementation; it now
+ raises ``NotImplementedError``. (Jelmer Vernooij, #717937)
+
+* ``bzrlib.deprecated_graph`` has been removed. ``bzrlib.graph``
+ scales better tree and should be used instead.
+ (Jelmer Vernooij, #733612)
+
+* ``ControlDirFormat.register_format`` has been removed. Instead,
+ ``Prober`` implementations should now implement a ``known_formats``
+ method. (Jelmer Vernooij)
+
+* ControlDirFormats can now provide a ``check_status`` method and
+ raise a custom exception or warning when an unsupported or deprecated
+ format is being opened. (Jelmer Vernooij, #731311)
+
+* ``bzrlib.revionspec.dwim_revspecs`` is deprecated.
+ Use ``bzrlib.revisionspec.RevisionSpec_dwim.append_possible_revspec`` and
+ ``bzrlib.revisionspec.RevisionSpec_dwim.append_possible_lazy_revspec``
+ instead. (Jelmer Vernooij, #721971)
+
+* ``BzrDirFormat`` has a new attribute ``fixed_components`` that
+ indicates whether the components of the bzrdir can be upgraded
+ independent of the ``BzrDir``. (Jelmer Vernooij)
+
+* ``BzrProber.register_format`` and ``BzrProber.unregister_format`` are
+ now deprecated in favour of the ``BzrProber.formats`` format registry.
+ (Jelmer Vernooij)
+
+* ``ControlDir`` implementations no longer have to provide the
+ ``get_branch_transport``, ``get_workingtree_transport`` and
+ ``get_repository_transport`` methods. (Jelmer Vernooij, #730325)
+
+* ``Converter`` has been moved from ``bzrlib.bzrdir`` to
+ ``bzrlib.controldir``. (Jelmer Vernooij)
+
+* Repository formats can now provide
+ ``_get_extra_interrepo_test_combinations`` in the same module
+ to provide extra test combinations for ``bzrlib.tests.per_repository``.
+ (Jelmer Vernooij)
+
+* Repository formats should now be registered on the format registry
+ (``bzrlib.repository.format_registry``) rather than using the class
+ methods on ``RepositoryFormat``. (Jelmer Vernooij)
+
+* Repository formats can now indicate they do not support the full
+ VersionedFiles API by setting the ``supports_full_versioned_files``
+ attribute to False. A subset of the VersionedFiles API
+ (signatures and text graphs) still needs to be supported.
+ (Jelmer Vernooij)
+
+* Repository formats have a new method ``is_deprecated`` that
+ implementations can override to return True to trigger a deprecation
+ warning. (Jelmer Vernooij)
+
+* The ``revision_id`` parameter of
+ ``Repository.search_missing_revision_ids`` and
+ ``InterRepository.search_missing_revision_ids`` is deprecated. It is
+ replaced by the ``revision_ids`` parameter. (Andrew Bennetts)
+
+* Working tree formats should now be registered on the format registry
+ (``bzrlib.working_tree.format_registry``) rather than using the class
+ methods on ``WorkingTreeFormat``. (Jelmer Vernooij, #714730)
+
+* Exporting may now be done with a generator
+ (``bzrlib.export.get_export_generator``) (Geoff/xaav, #791005)
+
+Internals
+*********
+
+* ``CatchingExceptionThread`` (formerly ThreadWithException) has been moved
+ out of the ``bzrlib.tests`` hierarchy to make it clearer that it can be used
+ outside of tests. This class makes it easier to track exceptions in threads
+ by catching them so they can be re-raised in the controlling thread. It's
+ available in the ``bzrlib.cethread`` module. (Vincent Ladeuil)
+
+* Correctly propagate malloc failures from diff-delta.c code as MemoryError
+ so OOM conditions during groupcompress are clearly reported. This entailed a
+ change to several function signatures. (Martin [gz], #633336)
+
+* ``HookPoint.lazy_hook`` and ``Hooks.install_named_lazy_hook`` can install
+ hooks for which the callable is loaded lazily. (Jelmer Vernooij)
+
+Testing
+*******
+
+* The Range parsing for HTTP requests will correctly parse incomplete ranges.
+ (Vincent Ladeuil, #731240)
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-2.5.txt b/doc/en/release-notes/bzr-2.5.txt
new file mode 100644
index 0000000..270ab2f
--- /dev/null
+++ b/doc/en/release-notes/bzr-2.5.txt
@@ -0,0 +1,1278 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 2.5.2
+#########
+
+:2.5.2: NOT RELEASED YET
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+* Revert use of --no-tty when gpg signing commits. (Jelmer Vernooij, #1014570)
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+
+bzr 2.5.1
+#########
+
+:2.5.1: 2012-05-22
+
+This is a bugfix release. Most of the bugs dealt with https and colocated
+branches glitches. Upgrading is recommended for all users of earlier 2.5
+releases.
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+New Features
+************
+
+None.
+
+Improvements
+************
+
+* ``bzr rmbranch`` now supports removing colocated branches.
+ (Jelmer Vernooij, #920653)
+
+* ``bzr rmbranch`` no longer removes active branches unless ``--force``
+ is specified. (Jelmer Vernooij, #922953)
+
+Bug Fixes
+*********
+
+* Connecting with HTTPS via HTTP now correctly uses the host name of the
+ destination rather than the proxy when checking certificates.
+ (Martin Packman, #944696)
+
+* Fixed merge tool availability checking and invocation to search the
+ Windows App Path registry in addition to the PATH. (Gordon Tyler, #939605)
+
+* Fixed problem with getting errors about failing to open /dev/tty when using
+ Bazaar Explorer to sign commits. (Mark Grandi, #847388)
+
+* Fix UnicodeEncodeError when translated progress task messages contain
+ non-ascii text. (Martin Packman, #966934)
+
+* Make sure configuration options can provide their own help topic.
+ (Jelmer Vernooij, #941672)
+
+Documentation
+*************
+
+* The alpha-quality texinfo sphinx builder has been deprecated. Sphinx >=
+ 1.1.2 now provides a better one. Most of the documentation can now be
+ generated to the texinfo format with ``make texinfo-sphinx``. This will
+ generate both the ``.texi`` files and the ``.info`` ones.
+ (Vincent Ladeuil, #940164)
+
+API Changes
+***********
+
+None.
+
+Testing
+*******
+
+* Add support for pyftpdlib >= 0.7.0 and drop support for previous pyftpdlib
+ versions. (Vincent Ladeuil, #956027)
+
+* Run smoketest for setup.py isolated in a tempdir. (Martin Packman, #140874)
+
+
+bzr 2.5.0
+#########
+
+:Codename: Phillip
+:2.5.0: 2012-02-24
+
+This release marks the start of a new long-term-stable series. From here, we
+will only make bugfix releases on the 2.5 series (2.5.1, etc, and support it
+until April 2017), while 2.6 will become our new development series.
+
+This is a bugfix and polish release over the 2.4 series, with a large number
+of bugs fixed (~170 for the 2.5 series alone). The 2.5 series provides a
+faster smart protocol implementation for many operations, basic support for
+colocated branches. We have started translating bzr with the 2.5 series:
+https://translations.launchpad.net/bzr, more than 20 languages have already
+been registered but these are the early days, contributions welcome.
+
+Only a few bugfixes have been included since 2.5b6 so all known fixed bugs
+are included here.
+
+Users are encouraged to upgrade from the other stable series.
+
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+New Features
+************
+
+None.
+
+Improvements
+************
+
+* The names of colocated branches are used as branch nicks if no nick is
+ specified. (Aaron Bentley)
+
+Bug Fixes
+*********
+
+* Show locks in ``bzr info`` on control directories without a
+ repository. (Jelmer Vernooij, #936767)
+
+* Disable ssl certificate verification on osx and windows until a native
+ access to the the root certificates is provided there.
+ (Vincent Ladeuil, #929179)
+
+Testing
+*******
+
+* Stop depending on the particular CPython ordering of dictionary keys
+ when testing the result of BzrDir.get_branches.
+ (Wouter van Heyst)
+
+bzr 2.5b6
+#########
+
+:2.5b6: 2012-02-02
+
+This is the sixth (and last (really)) beta of the 2.5 series, leading to a
+2.5.0 release in March 2012. Beta releases are suitable for everyday use
+but may cause some incompatibilities with plugins.
+
+This introduces the support for colocated branches into the '2a' format in a
+backward compatible way, fix more glitches in the colocated UI, verify https
+certificates for the urllib https client implementation, fix some more
+unicode issues and more.
+
+All bugs fixed in previous series known at the time of this release are
+included.
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+New Features
+************
+
+* Support for colocated branches is now available in the default
+ format ("2a"). (Jelmer Vernooij)
+
+Improvements
+************
+
+* ``bzr switch -b`` in a standalone tree will now create a colocated branch.
+ (Jelmer Vernooij, #918197)
+
+* ``bzr info`` now reports when there are present (but unused) colocated
+ branches. (Jelmer Vernooij, #891646)
+
+* Checkouts can now be into target directories that already have
+ a control directory (but no branch or working tree).
+ (Jelmer Vernooij, #913980)
+
+* Colocated branches can now have names including forward slashes, to
+ allow for namespaces. (Jelmer Vernooij, #907980)
+
+* New HPSS call for ``BzrDir.get_branches``. (Jelmer Vernooij, #894460)
+
+* Checkouts of colocated branches are now always lightweight.
+ (Jelmer Vernooij, #918828)
+
+Bug Fixes
+*********
+
+* ``bzr branch`` now fetches revisions when branching into an empty
+ control directory. (Jelmer Vernooij, #905594)
+
+* A sane default is provided for ``ssl.ca_certs`` which should points to the
+ Certificate Authority bundle for supported platforms.
+ (Vincent Ladeuil, #920455)
+
+* ``bzr branch`` generates correct target branch locations again if not
+ specified. (Jelmer Vernooij, #919218)
+
+* ``bzr send`` works on treeless branches again.
+ (Jelmer Vernooij, #921591)
+
+* ``bzr version`` no longer throws a UnicodeDecodeError if the .bzr.log path
+ contains non-ascii characters. (Martin Packman, #312841)
+
+* Support scripts that don't call bzrlib.initialize() but still call run_bzr().
+ (Vincent Ladeuil, #917733)
+
+* Test for equality instead of object identity where ROOT_PARENT is concerned.
+ (Wouter van Heyst, #881142)
+
+* urllib-based HTTPS client connections now verify the server certificate
+ validity as well as the hostname.
+ (Jelmer Vernooij, Vincent Ladeuil, #651161)
+
+
+API Changes
+***********
+
+* ``config.config_dir`` and related functions now always return paths as
+ unicode. (Martin Packman, #825826)
+
+* ``ControlDir`` now has a new method ``set_branch_reference`` which can
+ be used for setting branch references. (Jelmer Vernooij)
+
+* ``ControlDir.destroy_branch`` now raises ``NotBranchError`` rather than
+ ``NoSuchFile`` if the branch didn't exist. (Jelmer Vernooij, #921693)
+
+Internals
+*********
+
+* A new matcher ``RevisionHistoryMatches`` has been added. (Jelmer Vernooij)
+
+* Add new module ``bzrlib.url_policy_open``. (Jelmer Vernooij, #850843)
+
+* ``MutableTree`` has two new hooks ``pre_transform`` and
+ ``post_transform`` that are called for tree transform operations.
+ (Jelmer Vernooij, #912084)
+
+
+Testing
+*******
+
+* Be more careful about closing open files for pypy interoperability.
+ (Wouter van Heyst)
+
+bzr 2.5b5
+#########
+
+:2.5b5: 2012-01-12
+
+This is the fifth (and last) beta of the 2.5 series, leading to a 2.5.0
+release in February 2012. Beta releases are suitable for everyday use but
+may cause some incompatibilities with plugins.
+
+This release includes many improvements in the smart server, UI polish for
+the colocated branches, enhancements to the config framework and more
+internal uses, bug fixes related to unicode and locale support and more.
+
+All bug fixed in previous series known at the time of this release are
+included.
+
+External Compatibility Breaks
+*****************************
+
+* The '.bzr/branch/email' file is no longer read to determine the users'
+ identity. Instead, the 'email' setting in '.bzr/branch/branch.conf'
+ should be used. (Jelmer Vernooij, #903894)
+
+New Features
+************
+
+* "bzr mkdir" now includes -p (--parents) option for recursively adding
+ parent directories.
+ (Jared Hance, Jelmer Vernooij, #253529)
+
+* ``config.Option`` can now declare ``override_from_env``, a list of
+ environment variables which, when set, that takes precedence over values
+ defined in configuration files. (Vincent Ladeuil, #907279)
+
+Improvements
+************
+
+* New HPSS call for ``Repository.reconcile``. (Jelmer Vernooij, #894455)
+
+* Merge now has two new hooks ``pre_merge`` and ``post_merge``
+ that are called before and after a merge and can make
+ additional modifications to the trees involved.
+ (Jelmer Vernooij, #906877)
+
+* Override the value returned by ``sys.getfilesystemencoding()`` for the bzr
+ script to utf-8 when it would otherwise be ascii on a posix system. This
+ will mean bzr works with non-ascii files when no locale or an incorrect
+ locale is set. (Martin Packman, #794353)
+
+* ``bzr branches`` now indicates the active colocated branch.
+ (Jelmer Vernooij, #891667)
+
+* ``bzr push`` now suggests using :parent if there is a parent location
+ set. (Jelmer Vernooij)
+
+* ``bzr send`` now only opens a single connection, rather than two,
+ to the target branch. (Jelmer Vernooij)
+
+Bug Fixes
+*********
+
+* Allow configuration option default value to be a python callable at
+ registration. (Vincent Ladeuil, #832064)
+
+* ``bzr config`` will now display the section ``[DEFAULT]`` used in
+ ``bazaar.conf``. (Vincent Ladeuil, #907268)
+
+* Configuration stores can now provides a specific quoting mechanism. This
+ is required to workaround ``configobj`` conflating quoting and list values
+ automatic conversion. (Vincent Ladeuil, #906897)
+
+* Create obsolete_packs directory when repacking if it does not
+ exist. (Jonathan Riddell, Jelmer Vernooij, #314314)
+
+* Fallback to the slower ``bzr log`` implementation when displaying a range
+ of revisions whose ancestry is not obviously on the same developement
+ line. (Vincent Ladeuil, #904744)
+
+* Make lazy imports resilient when resolved concurrently from multiple
+ threads. Now the stand-in object will behave as a proxy for the real object
+ after the initial access, rather than throwing. Assigning the object to
+ multiple names should still be avoided. (Martin von Gagern, #396819)
+
+* Not setting ``gpg_signing_key`` or setting it to ``default`` will use the
+ user email (obtained from the ``email`` configuration option or its
+ default value). (Vincent Ladeuil, Jelmer Vernooij, #904550)
+
+* Prevent spurious InconsistentDelta error when committing a move of a
+ non-ascii directory with contents. (Rory Yorke, #185211)
+
+* Properly ignore '\n' in an option reference since this cannot be part of a
+ config option identifier. (Vincent Ladeuil, #902125)
+
+* Make sure that the bzr probers are always registered when
+ bzrlib.workingtree is imported. (Jelmer Vernooij, #905218)
+
+* Report mistake trying to move a removed file with a non-ascii name without
+ UnicodeEncodeError being raised. (Martin Packman, #898541)
+
+* Safely unquote configuration values in weird edge cases (a section seen as
+ a dictionary which is not a supported use case for the configuration
+ stacks). (Vincent Ladeuil, #908050)
+
+* Stop altering ``sys.platform`` on OSX when initialising the locale.
+ (Martin Packman, #570495)
+
+* Uncommit no longer removes tags if they are part of the working
+ trees pending merges. (Jelmer Vernooij, #905462)
+
+API Changes
+***********
+
+* ``Config.signature_needed``, ``Config.signing_policy``,
+ ``Config.gpg_signing_key``, ``Config.gpg_signing_command``,
+ ``Config.checking_policy`` and ``Config.post_commit`` are now deprecated.
+ (Jelmer Vernooij)
+
+* ``Repository.get_commit_builder`` now takes a ``config_stack``
+ rather than a ``config`` argument. (Jelmer Vernooij)
+
+* Scripts using bzrlib should now ensure setlocale is called on posix
+ platforms if they need a non-ascii user encoding. (Martin Packman)
+
+* Send formats now accept a new optional argument ``submit_branch``,
+ which can be None or a Branch object for the submit branch location.
+ (Jelmer Vernooij)
+
+* ``VersionedFileRepository.add_revision`` no longer takes a ``config``
+ argument. (Jelmer Vernooij)
+
+Internals
+*********
+
+* Add HPSS call for ``Branch.get_checkout_format``. (Jelmer Vernooij, #894459)
+
+* Add HPSS call for ``Repository.pack``. (Jelmer Vernooij, #894461)
+
+* Add HPSS calls for ``Repository.iter_files_bytes``, speeding up
+ several commands including ``bzr export`` and ``bzr co --lightweight``.
+ (Jelmer Vernooij, #608640)
+
+* All bzr control directories, branch formats, repository formats and
+ working tree formats now support feature flags, which are
+ serialized in their respective format files. See
+ ``doc/developers/feature-flags.txt`` for details.
+ (Jelmer Vernooij)
+
+* ``bzrlib.urlutils`` now includes ``quote`` and ``unquote`` functions,
+ rather than importing them from ``urllib``. This prevents loading
+ of the ``socket``, ``ssl`` and ``urllib`` modules for
+ local bzr operations. (Jelmer Vernooij)
+
+* Configuration options can be SI units by using ``int_SI_from_unicode`` as
+ their ``convert_from_unicode`` helper. (Vincent Ladeuil)
+
+* Configuration stacks can now use ``StartingPathMatcher`` to select the
+ sections matching a location while respecting the order chosen by the user
+ in the configuration file: from generic sections to specific
+ sections. (Vincent Ladeuil, #832046).
+
+* Configuration stores can now save incremental changes by using
+ ``save_changes()`` instead of ``save()``. This reduces the number or
+ required input/outputs and allows stores to be shared between
+ stacks. (Vincent Ladeuil)
+
+* ControlDir now has a get_branches method that returns a dictionary
+ whose keys are the names of the branches and whose values are the
+ branches themselves. The active branch uses the key None.
+ (Neil Martinsen-Burrell)
+
+* Helper ``osutils.path_from_environ`` added for extracting a unicode path
+ from an environment variable. (Martin Packman, #832028)
+
+* Helper ``win32utils.get_environ_unicode`` added for avoiding encoding
+ problems with ``os.environ.get`` use. (Martin Packman, #262874)
+
+* Lazy imports can now only be absolute. (Jelmer Vernooij)
+
+* Merge3Mergers now have an optional ``other_branch`` argument
+ which contains the branch from which the ``other_tree``
+ was obtained, if any. (Jelmer Vernooij)
+
+* MutableTree now has a hook ``post_build_tree`` which is called after
+ a new mutable tree has been created. (Jelmer Vernooij, #912765)
+
+* New HPSS call ``BzrDir.checkout_metadir``. (Jelmer Vernooij, #894459)
+
+* New HPSS call ``VersionedFileRepository.get_inventories``,
+ speeding up various commands including ``bzr export``,
+ ``bzr checkout`` and ``bzr cat``. (Jelmer Vernooij, #608640)
+
+* The ``ConfigCommandLineStore`` is now supported by ``bzr config`` and is
+ seen as single no-name section of configuration options. (Vincent Ladeuil)
+
+Testing
+*******
+
+* New matcher ``ContainsNoVfsCalls`` which filters a list of HPSS
+ calls for VFS requests. (Jelmer Vernooij)
+
+* New ``MemoryStack`` class allows for diskless tests and locally injected
+ configuration stacks. Lower level tests for predefined set of options can
+ be written without setting up configuration files. (Vincent Ladeuil)
+
+
+bzr 2.5b4
+#########
+
+:2.5b4: 2011-12-08
+
+This is the fourth beta of the 2.5 series, leading to a 2.5.0 release in
+February 2012. Beta releases are suitable for everyday use but may cause
+some incompatibilities with plugins.
+
+This release includes many improvements in the smart server, UI polish for
+the colocated branches, optimizations for revision specifiers to avoid
+history sized operations, enhancements to the config framework, bug fixes
+related to unicode paths and more.
+
+All bug fixed in previous series known at the time of this release are
+included.
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+New Features
+************
+
+* Provides a ``po_merge`` plugin to automatically merge ``.po`` files with
+ ``msgmerge``. See ``bzr help po_merge`` for details.
+ (Vincent Ladeuil, #884270)
+
+Improvements
+************
+
+* ``bzr branch --stacked`` now only makes a single connection to the remote
+ server rather than three. (Jelmer Vernooij, #444293)
+
+* ``bzr export --uncommitted`` will export the uncommitted tree.
+ (Jelmer Vernooij, #555613)
+
+* ``bzr rmbranch`` can now remove colocated branches.
+ (Jelmer Vernooij, #831464)
+
+* ``bzr status`` no longer shows shelves if files are specified.
+ (Francis Devereux)
+
+* ``bzr switch`` now accepts colocated branch names to switch to.
+ (Jelmer Vernooij, #826814)
+
+* Plugins can now register additional "location aliases".
+ (Jelmer Vernooij)
+
+* Revision specifiers will now only browse as much history as they
+ need to, rather than grabbing the whole history unnecessarily in some
+ cases. (Jelmer Vernooij)
+
+* When using ``bzr switch`` to switch to a sibling of the current
+ branch, the relative branch name should no longer be url-encoded.
+ (Jelmer Vernooij)
+
+Bug Fixes
+*********
+
+* A new section local option ``basename`` is available to help support some
+ ``bzr-pipeline`` workflows and more generally help mapping local paths to
+ remote ones. See ``bzr help configuration`` for more details.
+ (Vincent Ladeuil, #843211)
+
+* Add HPSS call for looking up revision numbers from revision ids on
+ remote repositories. (Jelmer Vernooij, #640253)
+
+* Add HPSS call for retrieving file contents from remote repositories.
+ Should improve performance for lightweight checkouts and exports of
+ from remote repositories. (Jelmer Vernooij, #368717, #762330, #608640)
+
+* Allow lazy compiled patterns from ``bzrlib.lazy_regex`` to be
+ pickled. (Jelmer Vernooij, #893149)
+
+* ``bzr info`` no longer shows empty output if only a control
+ directory is present. (Jelmer Vernooij, #159098)
+
+* Cope with missing revision ids being specified to
+ ``Repository.gather_stats`` HPSS call. (Jelmer Vernooij, #411290)
+
+* Fix test failures on windows related to locations.conf handling.
+ (Vincent Ladeuil, #892992)
+
+* Fixed parsing of the timestamp given to ``commit --commit-time``. Now
+ prohibits several invalid strings, reads the correct number of seconds,
+ and gives a better error message if the time zone offset is not given.
+ (Matt Giuca, #892657)
+
+* Give meaningful file/line references when reporting deprecation warnings
+ for _CompatabilityThunkFeature based test features.
+ (Vincent Ladeuil, #897718)
+
+* Make reporting of mistakes involving unversioned files with non-ascii
+ filenames work again without 'Unprintable exception' being shown.
+ (Martin Packman, #898408)
+
+* Provide names for lazily registered hooks.
+ (Neil Martinsen-Burrell, #894609)
+
+* Raise BadIndexKey exception in btree_index when a key is too large, fixing
+ an infinite recursion issue. (Shannon Weyrick, #720853)
+
+* Resolve regression from colocated branch path handling, by ensuring that
+ unreserved characters are unquoted in URLs. (Martin Packman, #842223)
+
+* Split segments from URLs for colocated branches without assuming the
+ combined form is valid. (Martin Packman, #842233)
+
+* Support looking up revision numbers by revision id in empty branches.
+ (Jelmer Vernooij, #535031)
+
+* Support verifying signatures on remote repositories.
+ (Jelmer Vernooij, #889694)
+
+* Teach the bzr client how to reconnect if we get ``ConnectionReset``
+ while making an RPC request. This doesn't handle all possible network
+ disconnects, but it should at least handle when the server is asked to
+ shutdown gracefully. (John Arbash Meinel, #819604)
+
+* When a remote format is unknown, bzr will now print a single-line error
+ message rather than a backtrace. (Jelmer Vernooij, #687226)
+
+API Changes
+***********
+
+* ``BzrDir.open_branch`` and ``BranchFormat.open`` now take an optional
+ ``possible_transports`` argument. (Jelmer Vernooij)
+
+* New method ``Transport.set_segment_parameter``. (Jelmer Vernooij)
+
+* ``Repository.verify_revision`` has been renamed to
+ ``Repository.verify_revision_signature``. (Jelmer Vernooij)
+
+* ``RevisionSpec.wants_revision_history`` now defaults to ``False`` and
+ is deprecated. The ``revs`` argument of
+ ``RevisionInfo.from_revision_id`` is now deprecated. (Jelmer Vernooij)
+
+* ``Tree.get_file_by_path`` is now deprecated. Use ``Tree.get_file`` instead.
+ (Jelmer Vernooij, #666897)
+
+* Some global options for use with commands have been removed, construct
+ an ``Option`` with the name instead. (Martin Packman)
+
+* The unused exception ``HistoryMissing`` has been removed.
+ (Jelmer Vernooij)
+
+Internals
+*********
+
+* Add HPSS call for ``Repository.pack``. (Jelmer Vernooij, #894461)
+
+* ``bzr config`` uses the new configuration implementation.
+ (Vincent Ladeuil)
+
+* Custom HPSS error handlers can now be installed in the smart server client
+ using the ``error_translators`` and ``no_context_error_translators``
+ registries. (Jelmer Vernooij)
+
+* New HPSS calls ``Repository.has_signature_for_revision_id``,
+ ``Repository.make_working_trees``, ``BzrDir.destroy_repository``,
+ ``BzrDir.has_workingtree``, ``Repository.get_physical_lock_status``,
+ ``Branch.get_physical_lock_status``,
+ ``Branch.put_config_file``, ``Branch.break_lock``,
+ ``BzrDir.destroy_branch``, ``Repository.break_lock``,
+ ``VersionedFileRepository.get_serializer_format``,
+ ``Repository.all_revision_ids``, ``Repository.start_write_group``,
+ ``Repository.commit_write_group``, ``Repository.abort_write_group``
+ ``Repository.check_write_group``, ``Repository.iter_revisions``,
+ ``Repository.add_signature_revision_text`` and
+ ``Repository.get_revision_signature_text``.
+ (Jelmer Vernooij)
+
+* ``RemoteBranch.get_config_stack`` and ``RemoteBzrDir.get_config_stack``
+ will now use HPSS calls where possible. (Jelmer Vernooij)
+
+* The registry of merge types has been moved to ``merge`` from ``option`` but
+ ``merge.get_merge_type_registry`` remains as an accessor. (Martin Packman)
+
+Testing
+*******
+
+* Avoid failures in test_transform when OS error messages are localised.
+ (Martin Packman, #891582)
+
+* Tests are now subject to a time limit: by default 300s, and 120s when
+ run from 'make check', controlled by the `selftest.timeout`
+ configuration option. This is currently not supported on Windows.
+ (Martin Pool)
+
+bzr 2.5b3
+#########
+
+:2.5b3: 2011-11-10
+
+This is the third beta of the 2.5 series, leading to a 2.5.0 release in
+February 2012. Beta releases are suitable for everyday use but may cause
+some incompatibilities with plugins.
+
+This release includes log options for ``push`` and ``pull``, more UI polish
+for colocated branches, a better and more coherent implementation for UI
+dialogs, enhancements to the config framework and more.
+
+This release includes all bug fixed in previous series known at the time of
+this release.
+
+External Compatibility Breaks
+*****************************
+
+None
+
+New Features
+************
+
+* The ``log_format`` configuration can be used with ``-Olog_format=line`` to
+ change the format ``push`` and ``pull`` use to display the
+ revisions. I.e.: ``bzr pull -v -Olog_format=short`` will use the ``short``
+ format instead of the default ``long`` one. (Vincent Ladeuil, #861472)
+
+* The new config scheme allows an alternative syntax for the 'appenpath'
+ policy relying on option expansion and defining a new 'relpath' option
+ local to a section. Instead of using '<option>:policy=appendpath', the
+ option value can de defined as 'option=xxxx/{relpath}'.
+ (Vincent Ladeuil, #832013)
+
+Improvements
+************
+
+* ``bzr info -v`` now shows the number of colocated branches
+ for control directories that support them.
+ (Jelmer Vernooij, #863285)
+
+* ``bzr version-info`` now takes a ``--revision`` argument.
+ (Jelmer Vernooij, #238705)
+
+* ``bzr revno`` now takes a ``--revision`` argument.
+ (Jelmer Vernooij, #870649)
+
+* ``bzr serve`` now can serve from URLs rather than just from the
+ file system. I.e.: ``bzr serve -d lp:bzr`` or
+ ``bzr serve -d file:///data/bzr`` (Jelmer Vernooij)
+
+* all input prompts are now char-based when possible, and can be forced to
+ line-based mode by setting the ``BZR_TEXTUI_INPUT`` environment variable
+ to 'line-based'. This replace the previous shelf UI only patch using
+ ``INSIDE_EMACS``. (Benoît Pierre)
+
+Bug Fixes
+*********
+
+* ``bzr info`` now shows the master branch location too for
+ treeless local branches. (Jelmer Vernooij, #258355)
+
+* ``bzr mkdir --quiet`` now does not print a line for every created
+ directory. (Martin von Gagern, #869915)
+
+* ``bzr mv`` does not crash when attempting to move the root of a
+ branch. (Jonathan Riddell, #809728)
+
+* ``bzr shelve`` now use ``UIFactory.choose`` for input handling, making
+ it usable when creating a custom ``UIFactory`` implementation. (Benoît
+ Pierre)
+
+* ``bzr clean-tree`` now use ``UIFactory.get_boolean`` for confirmation
+ prompt, making it usable when using a custom ``UIFactory``
+ implementation. (Benoît Pierre)
+
+* If sending a crash through Apport fails report the Apport failure to
+ bzr.log rather than stderr. (Jonathan Riddell, #766735)
+
+* ``bzr upgrade`` no longer treats 'already up-to-date' exceptions as
+ errors. (Benoît Pierre, #716560).
+
+* ``bzr version-info`` no longer populates the clean state for custom
+ templates unless {clean} is explicitly asked for.
+ (Lawrence Mitchell, #882541)
+
+* Fix finding the CPU count when using Python >= 2.6 on BSD-based systems.
+ (Jelmer Vernooij, #887151)
+
+* ``WorkingTree.clone()`` now supports its ``revision_id`` being set
+ to the null revision. (Jelmer Vernooij, #876423)
+
+* ``WorkingTree.pull`` can now pull ``NULL_REVISION``.
+ (Jelmer Vernooij, #887556)
+
+API Changes
+***********
+
+* ``Branch.revision_history`` is now deprecated. (Jelmer Vernooij, #799519)
+
+* Methods ``add`` and ``items`` of ``LRUCache`` and ``LRUSizeCache`` are
+ deprecated. Use normal dict-style access instead. (Martin Packman)
+
+* New flag ``RepositoryFormat.supports_unreferenced_revisions`` which
+ indicates whether revisions can be present in a repository without
+ being referenced from e.g. a branch history at the same time.
+ (Jelmer Vernooij)
+
+* ``UIFactory.choose`` has been added: prompt the user for a list of
+ choices. (Benoît Pierre)
+
+Internals
+*********
+
+* ``ControlDirFormat`` now has a new method ``supports_transport``
+ which format implementations can use whether or not they can access
+ a control dir over a particular transport. (Jelmer Vernooij)
+
+* ``BranchBuilder.build_commit`` now take ``parent_ids`` and
+ ``allow_leftmost_as_ghost`` arguments. (Jelmer Vernooij)
+
+Testing
+*******
+
+* Ensure TestCase instances are deallocated immediately after running where
+ possible. This greatly reduces the peak resource needs of a full test suite
+ run. The new ``-Euncollected_cases`` selftest flag will add failures if any
+ case which persists pasts its expected lifetime. (Martin Packman, #613247)
+
+* Report exceptions from child processes during fork instead of swallowing the
+ error and reporting that everything went okay. (Martin Packman, #804130)
+
+
+bzr 2.5b2
+#########
+
+This is the second beta of the 2.5 series, leading to a 2.5.0 release in
+February 2012. Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins.
+
+This release includes more filtering options for ``bzr log``, idle
+connections handling for ``bzr serve``, a ``development-colo`` experimental
+format to flesh out the colocated branches UI, better support for foreign
+formats, enhancements to the config framework and more.
+
+This release includes all bug fixed in previous series known at the time of
+this release.
+
+:2.5b2: 2011-10-06
+
+External Compatibility Breaks
+*****************************
+
+None
+
+New Features
+************
+
+* A new ``-O`` standard option (common to all commands) have been added. It
+ provides a value for a config option in the ``-Oname=value`` form that
+ takes precedence over all definitions found in config files. It can be
+ used multiple times to override different options.
+ (Vincent Ladeuil, #491196)
+
+* ``bzr log`` now has an option called ``--omit-merges`` to omit
+ those commits that merged branches, i.e. those having more than one
+ parent.
+ In order to avoid confusion, the previous command line option
+ ``--include-merges`` has been renamed to ``--include-merged``.
+ The old name of the command line option will still be accepted.
+ The name change also affects ``bzr missing``.
+ (Martin von Gagern)
+
+* ``bzr serve`` will now disconnect clients if they have not issued an RPC
+ request after 5minutes. On POSIX platforms, this will also happen for
+ ``bzr serve --inet``. This can be overridden with the configuration
+ variable ``serve.client_timeout`` or in the command line parameter
+ ``bzr serve --client-timeout=X``. Further, it is possible to request
+ ``bzr serve [--inet]`` to shutdown gracefully by sending SIGHUP. It will
+ finish the current request, and then close the connection.
+ (John Arbash Meinel, #824797, #795025)
+
+* The new experimental format ``development-colo`` supports colocated
+ branches. This format will eventually be merged back into the ``2a``
+ format when it has stabilized and there is adequate UI support for
+ colocated branches.
+ (Jelmer Vernooij, #831481)
+
+Improvements
+************
+
+* Fixed a bug where ``bzr tags -r x..y`` loaded the branch history once for
+ every revision in the range; it's now much faster. (Vincent Ladeuil, #857335)
+
+* ``bzr info -v`` can now be run against branches that don't support
+ ``last_revision_info``, in which case the branch information will simply
+ not be displayed. (Jelmer Vernooij)
+
+Bug Fixes
+*********
+
+* ``bzr shelve`` can now be used in emacs shells as the input handling is
+ turned into a line-based one when ``INSIDE_EMACS`` is set (which is the
+ case for all recent emacs versions). (Vincent Ladeuil, #856261)
+
+* ``bzr tags`` can now be used against remote repositories that do
+ not provide access to the revision graph. (Jelmer Vernooij, #858942)
+
+* ``bzr update PATH`` will stop if you seem to be asking it to update
+ anything less than a whole tree, because that's not supported by ``bzr``'s
+ concept that the whole tree has a single basis revision. Previously, it
+ would go ahead and update the whole tree, which was surprising.
+ (Martin Pool, #557886)
+
+* Don't crash if ``bzrlib.initialize()`` has not been called while accessing
+ configs. (Vincent Ladeuil, #863401)
+
+* Redirects between http and https no longer discard path information
+ in some cases. (Jelmer Vernooij, #853765)
+
+* The ``--overwrite`` argument to ``bzr push`` and ``bzr pull`` no longer
+ reports all tags as changed. (Jelmer Vernooij, #845396)
+
+* ``WorkingTree.get_file_mtime`` now raises NoSuchId if a file id is
+ specified that is unknown. (Jelmer Vernooij, #847435)
+
+
+API Changes
+***********
+
+* ``Branch.get_revision_delta`` has been deprecated. Use
+ ``Repository.get_revision_delta`` instead. (Jelmer Vernooij, #859712)
+
+* Plugins that implement custom protocols for ``bzr serve`` should now
+ also take an argument ``timeout``. This is used by the the bzr protocol
+ to close a connection if a client has been idle for more than X seconds.
+ (Default 5minutes). (John Arbash Meinel)
+
+* ``Repository.fileids_altered_by_revision_ids`` has been moved to
+ ``VersionedFileRepository`` and is no longer part of the standard
+ ``Repository`` interface. (Jelmer Vernooij)
+
+* The argument ``include_merges`` to ``missing.find_unmerged`` has
+ been renamed to ``include_merged``. The old name is still supported
+ for now but will cause a deprecation warning. (Martin von Gagern)
+
+* The new method ``ControlDirFormat.is_initializable()`` returns a boolean
+ indicating whether or not it is possible to use any of the
+ initialization methods of that format to create a new control dir.
+ (Jelmer Vernooij)
+
+Internals
+*********
+
+* ``Branch`` objects can now use a config stack with the newly introduced
+ ``get_config_stack()``. Both ``get_config`` and ``get_config_stack`` can
+ be used for the same branch but it's recommended to stick to one for a
+ given option.
+
+Testing
+*******
+
+* Test scripts can now use ``bzr shelve`` and provide their input as
+ complete lines. (Vincent Ladeuil, #856261)
+
+* Really corrupt the pack file without depending on a special length or value.
+ (Vincent Ladeuil, #807032)
+
+
+bzr 2.5b1
+#########
+
+:2.5b1: 2011-09-15
+
+This is the first beta of the 2.5 series, leading up to a 2.5.0
+release in February 2012.
+
+This release includes better support for gpg signing, better support for
+i18n (mostly command help and error messages), more options to filter ``bzr
+log`` output, more support for colocated branches ("location,branch=XXX"
+syntax), better feedback on updated tags for various commands, faster
+branching into an empty repository, enhancements to the config framework and
+more.
+
+Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins. Some plugins may need small updates to work
+with 2.5b1.
+
+External Compatibility Breaks
+*****************************
+
+None
+
+New Features
+************
+
+* A ``from_unicode`` parameter can be specified when registering a config
+ option. This implements boolean, integer and list config options when the
+ provided ``bool_from_store``, ``int_from_store`` and ``list_from_store``
+ are used for this parameter. (Vincent Ladeuil)
+
+* Accessing a packaging branch on Launchpad (eg, ``lp:ubuntu/bzr``) now
+ checks to see if the most recent published source package version for
+ that project is present in the branch tags. This should help developers
+ trust whether the packaging branch is up-to-date and can be used for new
+ changes. The level of verbosity is controlled by the config item
+ ``launchpad.packaging_verbosity``. It can be set to one of
+
+ off
+ disable all checks
+
+
+ minimal
+ only display if the branch is out-of-date
+
+ short
+ also display single-line up-to-date and missing,
+
+
+ all
+ (default) display multi-line content for all states
+
+
+ (John Arbash Meinel, #609187, #812928)
+
+* Add a config option gpg_signing_key for setting which GPG key should
+ be used to sign commits. Also default to using the gpg user identity
+ which matches user_email() as set by whoami.
+ (Jonathan Riddell, #68501)
+
+* An ``invalid`` parameter can be specified when registering a config option
+ to decide what should be done when invalid values are
+ encountered. 'warning' and 'error' will respectively emit a warning and
+ ignore the value or errors out. (Vincent Ladeuil)
+
+* bzr add now skips large files in recursive mode. The default "large"
+ size is 20MB, and is configurable via the add.maximum_file_size
+ option. A value of 0 disables skipping. Named items passed to add are
+ never skipped. (Shannon Weyrick, #54624)
+
+* ``bzr help configuration/<option>`` display the help for ``option`` for
+ all registered configuration options. (Vincent Ladeuil, #747050)
+
+* ``bzr log -m`` now matches message, author, committer and bugs instead
+ of just matching the message. ``--message`` keeps its original meaning,
+ while ``--match-message, --match-author, --match-committer`` and
+ ``--match-bugs`` match each of those fields. (Jacek Sieka)
+
+* ``config.Option`` can now declare ``default_from_env``, a list of
+ environment variables to get a default value from. (Vincent Ladeuil)
+
+* ``config.NameMatcher`` can be used to implement config stores and stacks
+ that need to provide specific option values for arbitrary unique IDs (svn
+ repository UUIDs, etc). (Vincent Ladeuil, #843638)
+
+* New builtin ``bzr branches`` command, which lists all colocated branches
+ in a directory. (Jelmer Vernooij, #826820)
+
+* Relative local paths can now be specified in URL syntax by using the
+ "file:" prefix. (Jelmer Vernooij)
+
+* Report commits signed with expired keys in ``verify-signatures``.
+ (Jonathan Riddell, #804254)
+
+* Translations are now enabled for command help, errors and globally
+ for any message using ``gettext`` given on output. (Jonathan Riddell,
+ INADA Naoki, #83941)
+
+Improvements
+************
+
+* ``bzr add`` will now warn about nested subtrees that are skipped.
+ (Jelmer Vernooij, #187342)
+
+* ``bzr commit -m ''`` can now be used to force an empty commit message.
+ Entering an empty commit message in the message editor still triggers
+ an error. (Jelmer Vernooij)
+
+* ``bzr pull`` will now mention how many tags it has updated.
+ (Jelmer Vernooij, #164450)
+
+* ``bzr tag`` no longer errors if a tag already exists but refers to the
+ same revision, and will mention when a tag has been updated
+ rather than created. (Jelmer Vernooij, #381203)
+
+* ``bzr uncommit`` will now remove tags that refer to removed revisions.
+ The ``--keep-tags`` option can be used to prevent this behaviour.
+ (Jelmer Vernooij, #605814)
+
+* Do not run i18n initialisation twice. (Jonathan Riddell)
+
+* Install translation .mo files. (Jonathan Riddell)
+
+* Locations printed by ``bzr upgrade`` are now formatted before display.
+ (Jelmer Vernooij)
+
+* ``Repository.get_parent_map`` now estimates the size of the returned
+ content more accurately. This means that we get closer to the desired
+ 64kB/request. For repositories converted from svn, this can be an
+ improvement of approx 5:1 in round trips to discover the whole history.
+ (John Arbash Meinel)
+
+* Support a ``bugtracker`` option which is used by ``bzr commit --fixes``
+ if no bug tracker was specified on the command line.
+ (Jelmer Vernooij, #334860)
+
+* Use ``gettext.NullTranslations`` in i18n to allow use of i18n even when
+ translations are not turned on. (Jonathan Riddell)
+
+Bug Fixes
+*********
+
+* ``bzr commit`` now correctly reports missing files as "removed", not
+ "modified". (Jelmer Vernooij, #553955)
+
+* ``bzr reconfigure`` will now allow multiple non-conflicting requests
+ in a single invocation, e.g. ``--branch`` and ``--use-shared``.
+ (Martin von Gagern, #842993)
+
+* A call to CHKInventory's filter-method will not result in a
+ DuplicateFileId error, if you move a subfolder and change a file in
+ that subfolder.
+ (Bastian Bowe, #809901)
+
+* Branching from a stacked branch no longer does a ``get_parent_map``
+ request for each revisions that is in the stacked-on repository while
+ determining what revisions need to be fetched. This mostly impacts
+ branching initialy into an empty shared repository when the source is
+ not the development focus. (John Arbash Meinel, #388269)
+
+* Decode ``BZR_HOME`` with fs encoding on posix platforms to avoid unicode
+ errors. (Vincent Ladeuil, #822571)
+
+* Fix fallout from URL handling changes in 2.5 that caused an IndexError to be
+ raised whenever a transport at the drive root was opened on windows.
+ (Martin [gz], #841322)
+
+* Fixed loading of external merge tools from config to properly decode
+ command-lines which contain embedded quotes. (Gordon Tyler, #828803)
+
+* Rather than an error being raised, a warning is now printed when the
+ current user does not have permission to read a configuration file.
+ (Jelmer Vernooij, #837324)
+
+* The pull command will now always use separate connections for the
+ case where the destination is a heavyweight checkout of some remote
+ branch on the same host as the source branch.
+ (Martin von Gagern, #483661)
+
+* TreeTransformBase.fixup_new_roots no longer forces trees to have a root, so
+ operations that use it, like merge, can now create trees without a root.
+ (Aaron Bentley)
+
+Documentation
+*************
+
+* Release instructions refreshed. (Vincent Ladeuil)
+
+API Changes
+***********
+
+* ``BranchFormat.initialize`` now takes a ``append_revisions_only``
+ argument. (Jelmer Vernooij)
+
+* ``Branch._get_checkout_format`` now takes a ``lightweight`` argument
+ which indicates if the format should be for a lightweight or a
+ heavyweight checkout. (Jelmer Vernooij)
+
+* ``ControlDir.create_branch`` now takes a ``append_revisions_only`` argument.
+ (Jelmer Vernooij)
+
+* New class ``URL`` in ``bzrlib.utils`` for managing parsed URLs.
+ (Jelmer Vernooij)
+
+* New method ``Config.get_user_option_as_int_from_SI`` added for expanding a
+ value in SI format (i.e. "20MB", "1GB") into its integer equivalent.
+ (Shannon Weyrick)
+
+* New method ``InterTree.file_content_matches`` which checks that
+ two files in different trees have the same contents.
+ (Jelmer Vernooij)
+
+* New method ``Tree.get_file_verifier`` which allows tree implementations
+ to return non-sha1 checksums to verify files.
+ (Jelmer Vernooij, #720831)
+
+* New methods ``get_transport_from_path`` and ``get_transport_from_url``
+ have been added that only support opening from a path or a URL,
+ unlike ``get_transport``. (Jelmer Vernooij)
+
+* New registry ``OptionRegistry`` specialized for configuration options.
+ (Vincent Ladeuil)
+
+* Remove ``AtomicFile.closed`` which has been deprecated in bzr 0.10.
+ (Vincent Ladeuil)
+
+* Remove ``commands._builtin_commands``, ``commands.shlex_split_unicode``,
+ ``Command._maybe_expand_globs`` and ``Command.run_direct`` deprecated in
+ 2.10 and 2.2.0. (Vincent Ladeuil)
+
+* Remove ``diff.get_trees_and_branches_to_diff`` deprecated in 2.2.0.
+
+* Remove ``log.calculate_view_revisions``, ``log._filter_revision_range``,
+ ``log.get_view_revisions`` which have been deprecated in bzr 2.1.0. Also
+ remove ``log.show_one_log`` which was never properly deprecated but wasn't
+ used and is easy to inline if needed. (Vincent Ladeuil)
+
+* Remove ``trace.info``, ``trace.error`` and ``trace.show_log_error``
+ deprecated in 2.1.0. (Vincent Ladeuil)
+
+* Remove ``TransportListRegistry.set_default_transport``, as the concept of
+ a default transport is currently unused. (Jelmer Vernooij)
+
+* Remove ``UIFactory.warn_cross_format_fetch`` and
+ ``UIFactory.warn_experimental_format_fetch`` in favor of
+ ``UIFactory.show_user_warning``. (Jelmer Vernooij)
+
+* ``Tags`` containers can now declare whether they support versioned
+ tags and whether tags can refer to ghost tags.
+ (Jelmer Vernooij)
+
+* ``Tags.merge_to`` now returns a dictionary with the updated tags
+ and a set of conflicts, rather than just conflicts. (Jelmer Vernooij)
+
+* There is a new class `ContentFilterTree` that provides a facade for
+ content filtering. The `filtered` parameter to `export` is deprecated
+ in favor of passing a filtered tree, and the specific exporter plugins
+ no longer support it.
+ (Martin Pool)
+
+* ``Transport`` now has a ``_parsed_url`` attribute instead of
+ separate ``_user``, ``_password``, ``_port``, ``_scheme``, ``_host``
+ and ``_path`` attributes. Proxies are provided for the moment but
+ may be removed in the future. (Jelmer Vernooij)
+
+Internals
+*********
+
+* A new debug flag ``hpss_client_no_vfs`` will now cause the HPSS client
+ to raise a ``HpssVfsRequestNotAllowed`` exception when a VFS request
+ is attempted. (Jelmer Vernooij)
+
+* New method ``ControlDir._get_selected_branch`` which returns the
+ colocated branch selected using path segment parameters.
+ (Jelmer Vernooij, #380871)
+
+Testing
+*******
+
+* Blackbox tests (including test scripts) can be debugged interactively (see
+ bzrlib.debug.BzrPdb for details). (Vincent Ladeuil)
+
+* `BranchBuilder.build_snapshot` now supports a "flush" action. This
+ cleanly and reliably allows tests using `BranchBuilder` to construct
+ branches that e.g. rename files out of a directory and unversion that
+ directory in the same revision. Previously some changes were impossible
+ due to the order that `build_snapshot` performs its actions.
+ (Andrew Bennetts)
+
+* Don't require ``os.fdatasync`` to be defined on all supported OSes
+ (BSD-based OSes don't define it). (Vincent Ladeuil, #822649)
+
+* Fix compatibility with testtools 0.9.12. (Jelmer Vernooij, #815423)
+
+* ``LockDir`` can now be run when the local hostname is ``localhost``.
+ (Jelmer Vernooij, #825994)
+
+* ``ModuleAvailableFeature`` won't try to import already imported modules,
+ allowing it to be used for modules with side-effects.
+ (Vincent Ladeuil, #712474)
+
+* Output time stamps while running ``make check`` to get better timings from
+ pqm. (Vincent Ladeuil, #837926)
+
+* `TestCaseWithMemoryTransport` is faster now: `_check_safety_net` now
+ just compares the bytes in the dirstate file to its pristine state,
+ rather than opening the WorkingTree and calling ``last_revision()``.
+ This reduces the overall test suite time by about 10% on my laptop.
+ (Andrew Bennetts)
+
+* Update `TestCase.knownFailure` to the testtools way of handling expected
+ failures to resolve Python 2.7 incompatibility. (Martin [gz], #607400)
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/bzr-2.6.txt b/doc/en/release-notes/bzr-2.6.txt
new file mode 100644
index 0000000..d17bdb1
--- /dev/null
+++ b/doc/en/release-notes/bzr-2.6.txt
@@ -0,0 +1,239 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr 2.6b2
+#########
+
+:2.6b2: 2012-09-10
+
+This is the second beta for the 2.6 series, leading up to a 2.6.0 release in
+August 2012.
+
+This release includes minor bug fixes.
+
+This release includes all bugs fixed in previous series known at the time of
+this release.
+
+Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins. Some plugins may need small updates to work
+with 2.6b2.
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+New Features
+************
+
+* New option ``--overwrite-tags`` for ``bzr pull`` and ``bzr push``.
+ (Jelmer Vernooij, #681792)
+
+Improvements
+************
+
+* Colocated branches can now be addressed using the 'co:NAME' rather than
+ the more complex 'file://.,branch=NAME'. (Jelmer Vernooij, #833665)
+
+Bug Fixes
+*********
+
+* "bzr missing" now shows tag names when displaying revision information.
+ (#559072, Neil Martinsen-Burrell)
+
+* Fix ``branch.conf`` saving when unlocking the branch for BranchFormat4.
+ (Vincent Ladeuil, #1020007)
+
+* Implement ``ResponseFile.readline`` and ``ReponseFile.tell``,
+ fixing some clones over HTTP. (Jelmer Vernooij, #963769)
+
+* Option values set on locked branches should be saved only when the branch
+ is finally unlocked. (Vincent Ladeuil, #948339)
+
+
+Documentation
+*************
+
+* Document "bzr lp-propose", "bzr register-branch" and
+ the other Launchpad plugin commands in bzr(1).
+ (Jelmer Vernooij, #843801, #163995)
+
+* Force format registration to avoid generate_docs.py traceback when the
+ registry is empty. (Vincent Ladeuil, #956860)
+
+* Generate ``ENVIRONMENT`` section in bzr(1) from known environment variable
+ list rather than hardcoding. (Jelmer Vernooij, #197618)
+
+
+API Changes
+***********
+
+* ``register_filter_stack_map`` and ``lazy_register_filter_stack_map``
+ are noew deprecated. Instead, use ``filter_stacks_registry.register``
+ and ``filter_stacks_registry.register_lazy``.
+ (Jelmer Vernooij)
+
+* Remove deprecated Branch.import_last_revision(). (Jelmer Vernooij)
+
+* Remove deprecated ``RepositoryFormat.register_format``.
+ (Jelmer Vernooij)
+
+* Remove deprecated Repository.get_ancestry(). (Jelmer Vernooij)
+
+* Remove deprecated Repository.iter_reverse_revision_history().
+ (Jelmer Vernooij)
+
+* The previously deprecated ``bzrlib.annotate.annotate_file`` function
+ has been removed. (Jelmer Vernooij)
+
+
+Internals
+*********
+
+None.
+
+Testing
+*******
+
+* Fix test failures by removing a remaining reference to ``features.sphinx``
+ which isn't needed anymore since we don't test the texinfo sphinx builder
+ anymore either. (Vincent Ladeuil)
+
+bzr 2.6b1
+#########
+
+:2.6b1: 2012-03-15
+
+This is the first beta for the 2.6 series, leading up to a 2.6.0 release in
+August 2012.
+
+This release includes ssl certificates verification from the urllib-based
+http implementation turned on by default, fixes some UI issues around
+colocated branches, documentation fixes and more.
+
+This release includes all bugs fixed in previous series known at the time of
+this release.
+
+Beta releases are suitable for everyday use but may cause some
+incompatibilities with plugins. Some plugins may need small updates to work
+with 2.6b1.
+
+External Compatibility Breaks
+*****************************
+
+None.
+
+Improvements
+************
+
+* Access to HTTPS URLs now uses the urrllib implementation by default.
+ For the old pycurl-based implementation, specify ``https+pycurl://`` as
+ the URL scheme when accessing a HTTPS location.
+ (Jelmer Vernooij, #125055)
+
+* Add short option alias ``-N`` for ``--no-recurse``.
+ (Jelmer Vernooij, #945904)
+
+* Avoid 'Invalid range access' errors when whole files are retrieved with
+ transport.http.get() . (Vincent Ladeuil, #924746)
+
+* ``bzr rmbranch`` now supports removing colocated branches.
+ (Jelmer Vernooij, #920653)
+
+* ``bzr rmbranch`` no longer removes active branches unless ``--force``
+ is specified. (Jelmer Vernooij, #922953)
+
+* ``bzr verify-signatures`` now shows a progress bar.
+ (Jelmer Vernooij)
+
+* Two new command hooks, ``pre_command`` and ``post_command``,
+ provide notification before and after a command has been run.
+ (Brian de Alwis, Jelmer Vernooij)
+
+Bug Fixes
+*********
+
+* Fix ``bzr config`` display for ``RegistryOption`` values.
+ (Vincent Ladeuil, #930182)
+
+Documentation
+*************
+
+* Prevent lines of command descriptions starting with a dot to
+ accidentally be interpreted as a roff macro in bzr(1).
+ (Jelmer Vernooij, #711079)
+
+* Properly format apostrophes in manual page. (Jelmer Vernooij, #234771)
+
+API Changes
+***********
+
+* ``GPGStrategy.do_verifications`` has been deprecated.
+ (Jelmer Vernooij)
+
+* File ids in the ``Tree`` API can now be bytestring as previously,
+ or tuples of bytestrings.
+ (Jelmer Vernooij)
+
+* ``mail_client`` now accepts a configuration stack object rather than
+ an old style Config object. (Jelmer Vernooij)
+
+* New method ``Repository.verify_revision_signatures``.
+ (Jelmer Vernooij)
+
+* New configuration option class ``RegistryOption`` which is backed
+ onto a registry. (Jelmer Vernooij)
+
+* New convenience API method ``WorkingTree.get_config_stack``.
+ (Jelmer Vernooij)
+
+* Remove
+ ``branch.PullResult.__int__`` deprecated in 2.3.0,
+ ``branch.PushResult.__int__`` deprecated in 2.3.0,
+ ``branch.BranchFormat.get_default_format`` deprecated in 2.4.0,
+ ``branch.BranchFormat.get_formats`` deprecated in 2.4.0,
+ ``branch.BranchFormat.set_default_format`` deprecated in 2.4.0,
+ ``branch.BranchFormat.register_format`` deprecated in 2.4.0,
+ ``branch.BranchFormat.unregister_format`` deprecated in 2.4.0,
+ ``bzrdir.BzrDir.generate_backup_name`` deprecated in 2.3.0,
+ ``bzrdir.BzrProber.register_bzrdir_format`` deprecated in 2.4.0,
+ ``bzrdir.BzrProber.unregister_bzrdir_format`` deprecated in 2.4.0,
+ ``config.Config.get_editor`` deprecated in 2.4.0,
+ ``hooks.known_hooks_key_to_parent_and_attribute`` deprecated in 2.3,
+ ``hooks.Hooks.create_hook`` deprecated in 2.4,
+ ``inventory.Inventory.__contains__`` deprecated in 2.4.0,
+ ``merge.Merge3Merger.scalar_three_way`` deprecated in 2.2.0,
+ ``merge.Merge3Merger.fix_root`` deprecated in 2.4.0,
+ ``transform.TreeTransformBase.has_named_child`` deprecated in 2.3.0,
+ ``transform.get_backup_name`` deprecated in 2.3.0,
+ ``transform._get_backup_name`` deprecated in 2.3.0,
+ ``workingtree.WorkingTreeFormat.get_default_format`` deprecated in 2.4.0,
+ ``workingtree.WorkingTreeFormat.register_format`` deprecated in 2.4.0,
+ ``workingtree.WorkingTreeFormat.register_extra_format`` deprecated in 2.4.0,
+ ``workingtree.WorkingTreeFormat.unregister_extra_format`` deprecated in 2.4.0,
+ ``workingtree.WorkingTreeFormat.get_formats`` deprecated in 2.4.0,
+ ``workingtree.WorkingTreeFormat.set_default_format`` deprecated in 2.4.0,
+ ``workingtree.WorkingTreeFormat.unregister_format`` deprecated in 2.4.0,
+ (Vincent Ladeuil)
+
+* Remove deprecated ``Branch.set_revision_history`` and
+ ``Branch.revision_history`` methods and the ``set_rh``
+ hook on ``Branch``. (Jelmer Vernooij)
+
+Internals
+*********
+
+* ``Tree.path2id`` now once again accepts a list of path elements
+ in addition to a path. (Jelmer Vernooij)
+
+* Turn config option expansion on by default. The only options for which
+ this should be disabled are templates which should already have used
+ conf.get(option, expand=False) or conf.get_user_option(option,
+ expand=False). (Vincent Ladeuil)
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/release-notes/release-template.txt b/doc/en/release-notes/release-template.txt
new file mode 100644
index 0000000..85987fb
--- /dev/null
+++ b/doc/en/release-notes/release-template.txt
@@ -0,0 +1,53 @@
+bzr ?.?.?
+#########
+
+:Codename: Nirvana
+:2.x.y: NOT RELEASED YET
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+
diff --git a/doc/en/release-notes/series-template.txt b/doc/en/release-notes/series-template.txt
new file mode 100644
index 0000000..67276bd
--- /dev/null
+++ b/doc/en/release-notes/series-template.txt
@@ -0,0 +1,62 @@
+####################
+Bazaar Release Notes
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+bzr ?.?.?
+#########
+
+:Codename: Nirvana
+:2.x.y: NOT RELEASED YET
+
+External Compatibility Breaks
+*****************************
+
+.. These may require users to change the way they use Bazaar.
+
+New Features
+************
+
+.. New commands, options, etc that users may wish to try out.
+
+Improvements
+************
+
+.. Improvements to existing commands, especially improved performance
+ or memory usage, or better results.
+
+Bug Fixes
+*********
+
+.. Fixes for situations where bzr would previously crash or give incorrect
+ or undesirable results.
+
+Documentation
+*************
+
+.. Improved or updated documentation.
+
+API Changes
+***********
+
+.. Changes that may require updates in plugins or other code that uses
+ bzrlib.
+
+Internals
+*********
+
+.. Major internal changes, unlikely to be visible to users or plugin
+ developers, but interesting for bzr developers.
+
+Testing
+*******
+
+.. Fixes and changes that are only relevant to bzr's test framework and
+ suite. This can include new facilities for writing tests, fixes to
+ spurious test failures and changes to the way things should be tested.
+
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/tutorials/centralized_workflow.txt b/doc/en/tutorials/centralized_workflow.txt
new file mode 100644
index 0000000..8ea2ce8
--- /dev/null
+++ b/doc/en/tutorials/centralized_workflow.txt
@@ -0,0 +1,318 @@
+=============================
+Centralized Workflow Tutorial
+=============================
+
+
+Overview
+========
+
+This document describes a possible workflow for using Bazaar_. That of
+using Bazaar_, the distributed version control system, in a centralized
+manner. Bazaar_ is designed to be very flexible and allows several
+different workflows, from fully decentralized to mostly centralized. The
+workflow used here is meant to ease a new user into more advanced usage of
+Bazaar_, and allow them to work in a mix of centralized and decentralized
+operations.
+
+In general, this document is meant for users coming from a background of
+centralized version control systems such as CVS or subversion. It is
+common in work settings to have a single central server hosting the
+codebase, with several people working on this codebase, keeping their work
+in sync. This workflow is also applicable to a single developer working
+on several different machines.
+
+.. _Bazaar: http://bazaar.canonical.com
+
+
+Initial Setup
+=============
+
+These are some reasonably simple steps to setup Bazaar_ so that it works
+well for you.
+
+
+Setting User Email
+------------------
+
+Your user identity is stored with each commit. While this doesn't have to
+be accurate or unique, it will be used in log messages and
+annotations, so it is better to have something real.
+
+::
+
+ % bzr whoami "John Doe <jdoe@organization.com>"
+
+
+Setting up a local Repository
+-----------------------------
+
+Bazaar_ branches generally copy the history information around with them,
+which is part of how you can work in a fully decentralized manner. As an
+optimization, it is possible for related branches to combine their storage
+needs so that you do not need to copy around all of this history
+information whenever you create a new branch.
+
+The best way to do this is to create a `Shared Repository`_. In
+general, branches will share their storage if they exist in a
+subdirectory of a `Shared Repository`_. So let's set up a `Shared
+Repository`_ in our home directory, thus all branches we create
+underneath will share their history storage.
+
+::
+
+ % bzr init-repo --trees ~
+
+
+Setting up a remote Repository
+---------------------------------
+
+Many times you want a location where data is stored separately from where
+you do your work. This workflow is required by centralized systems
+(CVS/SVN). Usually they are on separate machines, but not always. This is
+actually a pretty good setup, especially in a work environment. Since it
+ensures a central location where data can be backed up, and means that if
+something happens to a developer's machine, no committed work has to be
+lost.
+
+So let's set up a shared location for our project on a remote machine
+called ``centralhost``. Again, we will use a
+`Shared Repository`_ to optimize disk usage.
+
+::
+
+ % bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/
+
+You can think of this step as similar to setting up a new cvsroot, or
+subversion repository. The ``--no-trees`` option tells bzr to not
+populate the directory with a working tree. This is appropriate,
+since no one will be making changes directly in the branches within
+the central repository.
+
+Here we're using a ``bzr+ssh`` URL, which means to use Bazaar's own
+protocol on top of the SSH secure shell. See the Administrator Guide for
+information about setting up a bzr+ssh server.
+
+
+Migrating an existing project to Bazaar
+=======================================
+
+Now that we have a repository, let's create a versioned project. Most of
+the time, you will already have some code that you are working with,
+that you now want to version using Bazaar_. If the code was originally
+in source control, there are many ways to convert the project to Bazaar_
+without losing any history. However, this is outside the scope of this
+document. See `Tracking Upstream`_ for some possibilities (section
+"Converting and keeping history").
+
+.. _Tracking Upstream: http://wiki.bazaar.canonical.com/TrackingUpstream
+
+..
+ XXX: We really need a different document for discussing conversion of a
+ project. Right now TrackingUpstream is the best we have, though.
+
+
+Developer 1: Creating the first revision
+----------------------------------------
+
+So first, we want to create a branch in our remote Repository, where we
+want to host the project. Let's assume we have a project named
+"sigil" that we want to put under version control.
+
+::
+
+ % bzr init bzr+ssh://centralhost/srv/bzr/sigil
+
+This can be thought of as the "HEAD" branch in CVS terms, or as the "trunk"
+in Subversion terms. We will call this the ``dev`` branch.
+
+I prefer working in a subdirectory of my home directory to avoid collisions with all
+the other files that end up there. Also, we will want a project
+directory where we can hold all of the different branches we end up
+working on.
+
+::
+
+ % cd ~
+ % mkdir work
+ % cd work
+ % mkdir sigil
+ % cd sigil
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
+ % cd dev
+ % cp -ar ~/sigil/* .
+ % bzr add
+ % bzr commit -m "Initial import of Sigil"
+
+
+In the previous section, we created an empty branch (the ``/sigil``
+branch) on ``centralhost``, and then checkout out this empty branch
+onto our workstation to add files from our existing project. There
+are many ways to set up your working directory, but the steps above
+make it easy to handle working with feature/bugfix branches. And one
+of the strong points of Bazaar_ is how well it works with branches.
+
+At this point, because you have a 'checkout' of the remote branch, any
+commits you make in ``~/work/sigil/dev/`` will automatically be saved
+both locally, and on ``centralhost``.
+
+
+Developer N: Getting a working copy of the project
+--------------------------------------------------
+
+Since the first developer did all of the work of creating the project,
+all other developers would just checkout that branch. **They should
+still follow** `Setting User Email`_ and `Setting up a local Repository`_.
+
+To get a copy of the current development tree::
+
+ % cd ~/work/sigil
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
+
+Now that two people both have a checkout of
+``bzr+ssh://centralhost/srv/bzr/sigil``, there will be times when one of
+the checkouts will be out of date with the current version.
+At commit time, Bazaar_ will inform the user of this and prevent them from
+committing. To get up to date, use ``bzr update`` to update the
+tree with the remote changes. This may require resolving conflicts if the
+same files have been modified.
+
+
+Developing on separate branches
+===============================
+
+So far everyone is working and committing their changes into the same
+branch. This means that everyone needs to update fairly regularly and
+deal with other people's changes. Also, if one person commits something
+that breaks the codebase, then upon syncing, everyone will get the
+problem.
+
+Usually, it is better to do development on different branches, and then
+integrate those back into the main branch, once they are stable. This is
+one of the biggest changes from working with CVS/SVN. They both allow you
+to work on separate branches, but their merging algorithms are fairly
+weak, so it is difficult to keep things synchronized. Bazaar_ tracks
+what has already been merged, and can even apply changes to files that
+have been renamed.
+
+
+Creating and working on a new branch
+------------------------------------
+
+We want to keep our changes available for other people, even if they
+aren't quite complete yet. So we will create a new public branch on
+``centralhost``, and track it locally.
+
+::
+
+ % cd ~/work/sigil
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
+ bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
+ % cd doodle-fixes
+
+We now have a place to make any fixes we need to ``doodle``. And we would
+not interrupt people who are working on other parts of the code. Because
+we have a checkout, any commits made in the ``~/work/sigil/doodle-fixes/``
+will also show up on ``centralhost``. [#nestedbranches]_ It is also
+possible to have two developers collaborate on one of these branches, just
+like they would have collaborated on the ``dev`` branch. [#cbranch]_
+
+.. [#nestedbranches] It may look odd to have a branch in a subdirectory of
+ another branch. This is just fine, and you can think of it as a
+ hierarchical namespace where the nested branch is derived from the
+ outer branch.
+
+.. [#cbranch] When using lots of independent branches, having to retype
+ the full URL all the time takes a lot of typing. We are looking into
+ various methods to help with this, such as branch aliases, etc. For
+ now, though, the bzrtools_ plugin provides the ``bzr cbranch`` command.
+ Which is designed to take a base branch, create a new public branch,
+ and create a checkout of that branch, all with much less typing.
+ Configuring ``cbranch`` is outside the scope of this document, but the
+ final commands are similar to:
+
+::
+
+ % bzr cbranch dev my-feature-branch
+
+.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
+
+
+Merging changes back
+--------------------
+
+When it is decided that some of the changes in ``doodle-fixes`` are ready
+to be merged into the main branch, simply do::
+
+ % cd ~/work/sigil/dev
+ % bzr merge ../doodle-fixes
+
+Now the changes are available in the ``dev`` branch, but they have not
+been committed yet. This is the time when you want to review the final
+changes, and double check the code to make sure it compiles cleanly and
+passes the test suite. The commands ``bzr status`` and ``bzr diff`` are
+good tools to use here. Also, this is the time to resolve any conflicts.
+Bazaar_ will prevent you from committing until you have resolved these
+conflicts. That way you don't accidentally commit the conflict markers.
+The command ``bzr status`` will show the conflicts along with the other
+changes, or you can use ``bzr conflicts`` to just list conflicts. Use
+``bzr resolve file/name`` or ``bzr resolve --all`` once conflicts have
+been handled. [#resolve]_ If you have a conflict that is particularly
+difficult to solve you may want to use the ``bzr remerge`` command. It
+will let you try different merge algorithms, as well as let you see the
+original source lines (``--show-base``).
+
+.. [#resolve] Some systems make you resolve conflicts as part of the merge
+ process. We have found that it is usually easier to resolve conflicts
+ when you have the view of the entire tree, rather than just a single
+ file. It gives you much more context, and also lets you run tests as
+ you resolve the problems.
+
+
+Recommended Branching
+---------------------
+
+One very common way to handle all of these branches is to give each
+developer their own branch, and their own place to work in the central
+location. This can be done with::
+
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
+ bzr+ssh://centralhost/srv/bzr/sigil/user-a
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
+ bzr+ssh://centralhost/srv/bzr/sigil/user-b
+
+This gives each developer their own branch to work on. And, they can
+easily create a new feature branch for themselves with just [#cbranch]_
+::
+
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
+ bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
+ % cd ~/work/sigil
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature
+
+
+Glossary
+========
+
+Shared Repository
+-----------------
+
+Bazaar_ has the concept of a "Shared Repository". This is similar to
+the traditional concept of a repository in other VCSs like CVS and
+Subversion. For example, in Subversion you have a remote repository,
+which is where all of the history is stored, and locally you don't
+have any history information, only a checkout of the working tree
+files. Note that "Shared" in this context means shared between
+branches. It *may* be shared between people, but standalone branches
+can also be shared between people.
+
+In Bazaar_ terms, a "Shared Repository" is a location where multiple
+branches can **share** their revision history information. In order to
+support decentralized workflows, it is possible for every branch to
+store its own revision history information. But this is often
+inefficient, since related branches share history, and they might as
+well share the storage as well.
+
+
+..
+ vim: tw=74 ft=rst spell spelllang=en_us
diff --git a/doc/en/tutorials/index.txt b/doc/en/tutorials/index.txt
new file mode 100644
index 0000000..ceeb29f
--- /dev/null
+++ b/doc/en/tutorials/index.txt
@@ -0,0 +1,11 @@
+Tutorials
+=========
+
+.. toctree::
+ :maxdepth: 1
+
+ ../mini-tutorial/index
+ tutorial
+ using_bazaar_with_launchpad
+ centralized_workflow
+ licence
diff --git a/doc/en/tutorials/licence.txt b/doc/en/tutorials/licence.txt
new file mode 100644
index 0000000..2130060
--- /dev/null
+++ b/doc/en/tutorials/licence.txt
@@ -0,0 +1,7 @@
+Licence
+===============
+
+Copyright 2005-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
diff --git a/doc/en/tutorials/tutorial.txt b/doc/en/tutorials/tutorial.txt
new file mode 100644
index 0000000..e2c8c09
--- /dev/null
+++ b/doc/en/tutorials/tutorial.txt
@@ -0,0 +1,647 @@
+.. This file is in Python ReStructuredText format - it can be formatted
+.. into HTML or text. In the future we plan to extract the example commands
+.. and automatically test them.
+
+.. This text was previously on the wiki at
+.. http://bazaar.canonical.com/IntroductionToBzr
+.. but has been moved into the source tree so it can be kept in sync with
+.. the source and possibly automatically checked.
+
+===============
+Bazaar Tutorial
+===============
+
+
+Introduction
+============
+
+If you are already familiar with decentralized version control, then
+please feel free to skip ahead to "Introducing Yourself to Bazaar". If,
+on the other hand, you are familiar with version control but not
+decentralized version control, then please start at "How DVCS is
+different." Otherwise, get some coffee or tea, get comfortable and get
+ready to catch up.
+
+The purpose of version control
+==============================
+
+Odds are that you have worked on some sort of textual data -- the sources
+to a program, web sites or the config files that Unix system
+administrators have to deal with in /etc. The chances are also good that
+you have made some sort of mistake that you deeply regretted. Perhaps you
+deleted the configuration file for your mailserver or perhaps mauled the
+source code for a pet project. Whatever happened, you have just deleted
+important information that you would desperately like to get back. If this
+has ever happened to you, then you are probably ready for Bazaar.
+
+Version control systems (which I'll henceforth call VCS) such as
+Bazaar give you the ability to track changes for a directory by turning
+it into something slightly more complicated than a directory that we call
+a **branch**. The branch not only stores how the directory looks right
+now, but also how it looked at various points in the past. Then, when you
+do something you wish you hadn't, you can restore the directory to the way
+it looked at some point in the past.
+
+Version control systems give users the ability to save changes to a
+branch by "committing a **revision**". The revision created is essentially
+a summary of the changes that were made since the last time the tree was
+saved.
+
+These revisions have other uses as well. For example, one can comment
+revisions to record what the recent set of changes meant by providing an
+optional log message. Real life log messages include things like "Fixed
+the web template to close the table" and "Added SFTP suppport. Fixes #595"
+
+We keep these logs so that if later there is some sort of problem with
+SFTP, we can figure out when the problem probably happened.
+
+How DVCS is different
+=====================
+
+Many Version Control Systems (VCS) are stored on servers. If one wants to
+work on the code stored within a VCS, then one needs to connect to the
+server and "checkout" the code. Doing so gives one a directory in which a
+person can make changes and then commit. The VCS client then connects to
+the VCS server and stores the changes. This method is known as the
+centralized model.
+
+The centralized model can have some drawbacks. A centralized VCS requires
+that one is able to connect to the server whenever one wants to do version
+control work. This can be a bit of a problem if your server is on some other
+machine on the internet and you are not. Or, worse yet, you **are** on the
+internet but the server is missing!
+
+Decentralized Version Control Systems (which I'll call DVCS after this
+point) deal with this problem by keeping branches on the same machine as
+the client. In Bazaar's case, the branch is kept in the same place as
+the code that is being version controlled. This allows the user to save
+his changes (**commit**) whenever he wants -- even if he is offline. The
+user only needs internet access when he wants to access the changes in
+someone else's branch that are somewhere else.
+
+
+A common requirement that many people have is the need to keep track of
+the changes for a directory such as file and subdirectory changes.
+Performing this tracking by hand is a awkward process that over time
+becomes unwieldy. That is, until one considers version control tools such
+as Bazaar. These tools automate the process of storing data by creating
+a **revision** of the directory tree whenever the user asks.
+
+Version control software such as Bazaar can do much more than just
+storage and performing undo. For example, with Bazaar a developer can
+take the modifications in one branch of software and apply them to a
+related branch -- even if those changes exist in a branch owned by
+somebody else. This allows developers to cooperate without giving
+write access to the repository.
+
+Bazaar remembers the ''ancestry'' of a revision: the previous revisions
+that it is based upon. A single revision may have more than one direct
+descendant, each with different changes, representing a divergence in the
+evolution of the tree. By branching, Bazaar allows multiple people to
+cooperate on the evolution of a project, without all needing to work in
+strict lock-step. Branching can be useful even for a single developer.
+
+Introducing yourself to Bazaar
+==============================
+
+Bazaar installs a single new command, **bzr**. Everything else is a
+subcommand of this. You can get some help with ``bzr help``. Some arguments
+are grouped in topics: ``bzr help topics`` to see which topics are available.
+
+One function of a version control system is to keep track of who changed
+what. In a decentralized system, that requires an identifier for each
+author that is globally unique. Most people already have one of these: an
+email address. Bazaar is smart enough to automatically generate an email
+address by looking up your username and hostname. If you don't like the
+guess that Bazaar makes, then three options exist:
+
+1. Set an email address via ``bzr whoami``. This is the simplest way.
+
+ To set a global identity, use::
+
+ % bzr whoami "Your Name <email@example.com>"
+
+ If you'd like to use a different address for a specific branch, enter
+ the branch folder and use::
+
+ % bzr whoami --branch "Your Name <email@example.com>"
+
+#. Setting the email address in the ``~/.bazaar/bazaar.conf`` [1]_ by
+ adding the following lines. Please note that ``[DEFAULT]`` is case
+ sensitive::
+
+ [DEFAULT]
+ email=Your Name <email@isp.com>
+
+ As above, you can override this settings on a branch by branch basis
+ by creating a branch section in ``~/.bazaar/locations.conf`` and
+ adding the following lines::
+
+ [/the/path/to/the/branch]
+ email=Your Name <email@isp.com>
+
+
+#. Overriding the two previous options by setting the global environment
+ variable ``$BZR_EMAIL`` or ``$EMAIL`` (``$BZR_EMAIL`` will take
+ precedence) to your full email address.
+
+.. [1] On Windows, the users configuration files can be found in the
+ application data directory. So instead of ``~/.bazaar/branch.conf``
+ the configuration file can be found as:
+ ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``.
+ The same is true for ``locations.conf``, ``ignore``, and the
+ ``plugins`` directory.
+
+Creating a branch
+=================
+
+History is by default stored in the .bzr directory of the branch. In a
+future version of Bazaar, there will be a facility to store it in a
+separate repository, which may be remote.
+
+We create a new branch by running ``bzr init`` in an existing directory::
+
+ % mkdir tutorial
+ % cd tutorial
+ % ls -a
+ ./ ../
+ % pwd
+ /home/mbp/work/bzr.test/tutorial
+ %
+ % bzr init
+ % ls -aF
+ ./ ../ .bzr/
+ %
+
+As with CVS, there are three classes of file: unknown, ignored, and
+versioned. The **add** command makes a file versioned: that is, changes
+to it will be recorded by the system::
+
+ % echo 'hello world' > hello.txt
+ % bzr status
+ unknown:
+ hello.txt
+ % bzr add hello.txt
+ added hello.txt
+ % bzr status
+ added:
+ hello.txt
+
+
+If you add the wrong file, simply use ``bzr remove`` to make it
+unversioned again. This does not delete the working copy in this case,
+though it may in others [2]_.
+
+.. [2] ``bzr remove`` will remove the working copy if it is currently
+ versioned, but has no changes from the last committed version. You
+ can force the file to always be kept with the ``--keep`` option to
+ ``bzr remove``, or force it to always be deleted with ``--force``.
+
+Branch locations
+================
+
+All history is stored in a branch, which is just an on-disk directory
+containing control files. By default there is no separate repository or
+database as used in svn or svk. You can choose to create a repository if
+you want to (see the ``bzr init-repo`` command). You may wish to do this
+if you have very large branches, or many branches of a moderately sized
+project.
+
+You'll usually refer to branches on your computer's filesystem just by
+giving the name of the directory containing the branch. bzr also supports
+accessing branches over SSH, HTTP and SFTP, amongst other things::
+
+ % bzr log bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+ % bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+ % bzr log sftp://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+
+By installing bzr plugins you can also access branches using the rsync
+protocol.
+
+See the `Publishing your branch`_ section for more about how to put your
+branch at a given location.
+
+Reviewing changes
+=================
+
+Once you have completed some work, you will want to **commit** it to the
+version history. It is good to commit fairly often: whenever you get a
+new feature working, fix a bug, or improve some code or documentation.
+It's also a good practice to make sure that the code compiles and passes
+its test suite before committing, to make sure that every revision is a
+known-good state. You can also review your changes, to make sure you're
+committing what you intend to, and as a chance to rethink your work before
+you permanently record it.
+
+Two bzr commands are particularly useful here: **status** and **diff**.
+
+bzr status
+----------
+
+The **status** command tells you what changes have been made to the
+working directory since the last revision::
+
+ % bzr status
+ modified:
+ foo
+
+``bzr status`` hides "boring" files that are either unchanged or ignored.
+The status command can optionally be given the name of some files or
+directories to check.
+
+bzr diff
+--------
+
+The **diff** command shows the full text of changes to all files as a
+standard unified diff. This can be piped through many programs such as
+''patch'', ''diffstat'', ''filterdiff'' and ''colordiff''::
+
+ % bzr diff
+ === added file 'hello.txt'
+ --- hello.txt 1970-01-01 00:00:00 +0000
+ +++ hello.txt 2005-10-18 14:23:29 +0000
+ @@ -0,0 +1,1 @@
+ +hello world
+
+
+With the ``-r`` option, the tree is compared to an earlier revision, or
+the differences between two versions are shown::
+
+ % bzr diff -r 1000.. # everything since r1000
+ % bzr diff -r 1000..1100 # changes from 1000 to 1100
+
+The ``--diff-options`` option causes bzr to run the external diff program,
+passing options. For example::
+
+ % bzr diff --diff-options --side-by-side foo
+
+Some projects prefer patches to show a prefix at the start of the path
+for old and new files. The ``--prefix`` option can be used to provide
+such a prefix.
+As a shortcut, ``bzr diff -p1`` produces a form that works with the
+command ``patch -p1``.
+
+
+Committing changes
+==================
+
+When the working tree state is satisfactory, it can be **committed** to
+the branch, creating a new revision holding a snapshot of that state.
+
+bzr commit
+----------
+
+The **commit** command takes a message describing the changes in the
+revision. It also records your userid, the current time and timezone, and
+the inventory and contents of the tree. The commit message is specified
+by the ``-m`` or ``--message`` option. You can enter a multi-line commit
+message; in most shells you can enter this just by leaving the quotes open
+at the end of the line.
+
+::
+
+ % bzr commit -m "added my first file"
+
+You can also use the ``-F`` option to take the message from a file. Some
+people like to make notes for a commit message while they work, then
+review the diff to make sure they did what they said they did. (This file
+can also be useful when you pick up your work after a break.)
+
+Message from an editor
+----------------------
+
+If you use neither the ``-m`` nor the ``-F`` option then bzr will open an
+editor for you to enter a message. The editor to run is controlled by
+your ``$VISUAL`` or ``$EDITOR`` environment variable, which can be overridden
+by the ``editor`` setting in ``~/.bazaar/bazaar.conf``; ``$BZR_EDITOR`` will
+override either of the above mentioned editor options. If you quit the
+editor without making any changes, the commit will be cancelled.
+
+The file that is opened in the editor contains a horizontal line. The part
+of the file below this line is included for information only, and will not
+form part of the commit message. Below the separator is shown the list of
+files that are changed in the commit. You should write your message above
+the line, and then save the file and exit.
+
+If you would like to see the diff that will be committed as you edit the
+message you can use the ``--show-diff`` option to ``commit``. This will include
+the diff in the editor when it is opened, below the separator and the
+information about the files that will be committed. This means that you can
+read it as you write the message, but the diff itself wont be seen in the
+commit message when you have finished. If you would like parts to be
+included in the message you can copy and paste them above the separator.
+
+Marking bugs as fixed
+---------------------
+
+Many changes to a project are as a result of fixing bugs. Bazaar can keep
+metadata about bugs you fixed when you commit them. To do this you use the
+``--fixes`` option. This option takes an argument that looks like this::
+
+ % bzr commit --fixes <tracker>:<id>
+
+Where ``<tracker>`` is an identifier for a bug tracker and ``<id>`` is an
+identifier for a bug that is tracked in that bug tracker. ``<id>`` is usually
+a number. Bazaar already knows about a few popular bug trackers. They are
+bugs.launchpad.net, bugs.debian.org, and bugzilla.gnome.org. These trackers
+have their own identifiers: lp, deb, and gnome respectively. For example,
+if you made a change to fix the bug #1234 on bugs.launchpad.net, you would
+use the following command to commit your fix::
+
+ % bzr commit -m "fixed my first bug" --fixes lp:1234
+
+For more information on this topic or for information on how to configure
+other bug trackers please read `Bug Tracker Settings`_.
+
+.. _Bug Tracker Settings: ../user-reference/index.html#bug-tracker-settings
+
+Selective commit
+----------------
+
+If you give file or directory names on the commit command line then only
+the changes to those files will be committed. For example::
+
+ % bzr commit -m "documentation fix" commit.py
+
+By default bzr always commits all changes to the tree, even if run from a
+subdirectory. To commit from only the current directory down, use::
+
+ % bzr commit .
+
+
+Removing uncommitted changes
+============================
+
+If you've made some changes and don't want to keep them, use the
+**revert** command to go back to the previous head version. It's a good
+idea to use ``bzr diff`` first to see what will be removed. By default the
+revert command reverts the whole tree; if file or directory names are
+given then only those ones will be affected. ``bzr revert`` also clears the
+list of pending merges revisions.
+
+
+Ignoring files
+==============
+
+The .bzrignore file
+-------------------
+
+Many source trees contain some files that do not need to be versioned,
+such as editor backups, object or bytecode files, and built programs. You
+can simply not add them, but then they'll always crop up as unknown files.
+You can also tell bzr to ignore these files by adding them to a file
+called ``.bzrignore`` at the top of the tree.
+
+This file contains a list of file wildcards (or "globs"), one per line.
+Typical contents are like this::
+
+ *.o
+ *~
+ *.tmp
+ *.py[co]
+
+If a glob contains a slash, it is matched against the whole path from the
+top of the tree; otherwise it is matched against only the filename. So
+the previous example ignores files with extension ``.o`` in all
+subdirectories, but this example ignores only ``config.h`` at the top level
+and HTML files in ``doc/``::
+
+ ./config.h
+ doc/*.html
+
+To get a list of which files are ignored and what pattern they matched,
+use ``bzr ignored``::
+
+ % bzr ignored
+ config.h ./config.h
+ configure.in~ *~
+
+It is OK to have either an ignore pattern match a versioned file, or to
+add an ignored file. Ignore patterns have no effect on versioned files;
+they only determine whether unversioned files are reported as unknown or
+ignored.
+
+The ``.bzrignore`` file should normally be versioned, so that new copies
+of the branch see the same patterns::
+
+ % bzr add .bzrignore
+ % bzr commit -m "Add ignore patterns"
+
+
+bzr ignore
+----------
+
+As an alternative to editing the ``.bzrignore`` file, you can use the
+``bzr ignore`` command. The ``bzr ignore`` command takes filenames and/or
+patterns as arguments and then adds them to the ``.bzrignore`` file. If a
+``.bzrignore`` file does not exist the ``bzr ignore`` command will
+automatically create one for you, and implicitly add it to be versioned::
+
+ % bzr ignore tags
+ % bzr status
+ added:
+ .bzrignore
+
+Just like when editing the ``.bzrignore`` file on your own, you should
+commit the automatically created ``.bzrignore`` file::
+
+ % bzr commit -m "Added tags to ignore file"
+
+
+Global ignores
+--------------
+
+There are some ignored files which are not project specific, but more user
+specific. Things like editor temporary files, or personal temporary files.
+Rather than add these ignores to every project, bzr supports a global
+ignore file in ``~/.bazaar/ignore`` [1]_. It has the same syntax as the
+per-project ignore file.
+
+
+Examining history
+=================
+
+bzr log
+-------
+
+The ``bzr log`` command shows a list of previous revisions. The ``bzr log
+--forward`` command does the same in chronological order to get most
+recent revisions printed at last.
+
+As with ``bzr diff``, ``bzr log`` supports the ``-r`` argument::
+
+ % bzr log -r 1000.. # Revision 1000 and everything after it
+ % bzr log -r ..1000 # Everything up to and including r1000
+ % bzr log -r 1000..1100 # changes from 1000 to 1100
+ % bzr log -r 1000 # The changes in only revision 1000
+
+
+Branch statistics
+=================
+
+The ``bzr info`` command shows some summary information about the working
+tree and the branch history.
+
+
+Versioning directories
+======================
+
+bzr versions files and directories in a way that can keep track of renames
+and intelligently merge them::
+
+ % mkdir src
+ % echo 'int main() {}' > src/simple.c
+ % bzr add src
+ added src
+ added src/simple.c
+ % bzr status
+ added:
+ src/
+ src/simple.c
+
+
+Deleting and removing files
+===========================
+
+You can delete files or directories by just deleting them from the working
+directory. This is a bit different to CVS, which requires that you also
+do ``cvs remove``.
+
+``bzr remove`` makes the file un-versioned, but may or may not delete the
+working copy [2]_. This is useful when you add the wrong file, or decide that
+a file should actually not be versioned.
+
+::
+
+ % rm -r src
+ % bzr remove -v hello.txt
+ ? hello.txt
+ % bzr status
+ removed:
+ hello.txt
+ src/
+ src/simple.c
+ unknown:
+ hello.txt
+
+If you remove the wrong file by accident, you can use ``bzr revert`` to
+restore it.
+
+
+Branching
+=========
+
+Often rather than starting your own project, you will want to submit a
+change to an existing project. To do this, you'll need to get a copy of
+the existing branch. Because this new copy is potentially a new branch,
+the command is called **branch**::
+
+ % bzr branch lp:bzr bzr.dev
+ % cd bzr.dev
+
+This copies down the complete history of this branch, so we can do all
+operations on it locally: log, annotate, making and merging branches.
+There will be an option to get only part of the history if you wish.
+
+You can also get a copy of an existing branch by copying its directory,
+expanding a tarball, or by a remote copy using something like rsync.
+
+Following upstream changes
+==========================
+
+You can stay up-to-date with the parent branch by "pulling" in their
+changes::
+
+ % bzr pull
+
+After this change, the local directory will be a mirror of the source. This
+includes the ''revision-history'' - which is a list of the commits done in
+this branch, rather than merged from other branches.
+
+This command only works if your local (destination) branch is either an
+older copy of the parent branch with no new commits of its own, or if the
+most recent commit in your local branch has been merged into the parent
+branch.
+
+Merging from related branches
+=============================
+
+If two branches have diverged (both have unique changes) then ``bzr
+merge`` is the appropriate command to use. Merge will automatically
+calculate the changes that exist in the branch you're merging from that
+are not in your branch and attempt to apply them in your branch.
+
+::
+
+ % bzr merge URL
+
+
+If there is a conflict during a merge, 3 files with the same basename
+are created. The filename of the common base is appended with ".BASE",
+the filename of the file containing your changes is appended with
+".THIS" and the filename with the changes from the other tree is
+appended with ".OTHER". Using a program such as kdiff3, you can now
+comfortably merge them into one file. In order to commit you have to
+rename the merged file (".THIS") to the original file name. To
+complete the conflict resolution you must use the resolve command,
+which will remove the ".OTHER" and ".BASE" files. As long as there
+exist files with .BASE, .THIS or .OTHER the commit command will
+report an error.
+
+::
+
+ % kdiff3 file.BASE file.OTHER file.THIS
+ % mv file.THIS file
+ % bzr resolve file
+
+[**TODO**: explain conflict markers within files]
+
+
+Publishing your branch
+======================
+
+You don't need a special server to publish a bzr branch, just a normal web
+server. Just mirror the files to your server, including the .bzr
+directory. One can push a branch (or the changes for a branch) by one of
+the following three methods:
+
+* The best method is to use bzr itself to do it.
+
+ ::
+
+ % bzr push bzr+ssh://servername.com/path/to/directory
+
+ (The destination directory must already exist unless the
+ ``--create-prefix`` option is used.)
+
+* Another option is the ``rspush`` plugin that comes with BzrTools, which
+ uses rsync to push the changes to the revision history and the working
+ tree.
+
+* You can also copy the files around manually, by sending a tarball, or using
+ rsync, or other related file transfer methods. This is usually less safe
+ than using ``push``, but may be faster or easier in some situations.
+
+
+Moving changes between trees
+============================
+
+It happens to the best of us: sometimes you'll make changes in the wrong
+tree. Maybe because you've accidentally started work in the wrong directory,
+maybe because as you're working, the change turns out to be bigger than you
+expected, so you start a new branch for it.
+
+To move your changes from one tree to another, use
+
+::
+
+ % cd NEWDIR
+ % bzr merge --uncommitted OLDDIR
+
+This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
+It will not apply committed changes, even if they could be applied to NEWDIR
+with a regular merge. The changes will remain in OLDDIR, but you can use ``bzr
+revert OLDDIR`` to remove them, once you're satisfied with NEWDIR.
+
+NEWDIR does not have to be a copy of OLDDIR, but they should be related.
+The more different they are, the greater the chance of conflicts.
diff --git a/doc/en/tutorials/using_bazaar_with_launchpad.txt b/doc/en/tutorials/using_bazaar_with_launchpad.txt
new file mode 100644
index 0000000..789ba40
--- /dev/null
+++ b/doc/en/tutorials/using_bazaar_with_launchpad.txt
@@ -0,0 +1,488 @@
+===========================
+Using Bazaar with Launchpad
+===========================
+
+
+Motivation
+==========
+
+Communities are different to teams
+----------------------------------
+
+The team of people required to create the initial release
+of a piece of software may vary in size from one person
+to several thousand people. Depending on the requirements,
+the challenges involved, both technical and managerial,
+can be immense. As explained in the Bazaar User Guide, selecting
+"just right" processes and using tools like Bazaar to support
+matching workflows can greatly help.
+
+Success with software though requires more than a great team - it
+requires a healthy, active *community*. This group is typically
+far larger than the team as it includes everyone interested in
+the software: the team, users, training partners, support partners,
+third-party developers and so on.
+
+Great communities are well understood in the free software community.
+Their applicability extends well beyond that though: most
+successful commercial software vendors are well skilled at
+building and managing the communities that grow up around
+their flagship products.
+
+Like great teams, great communities don't just happen.
+Good policies and guidelines are essential for
+fostering the right sort of behaviour and healthy
+relationships between participants. For a deeper look at
+this topic, see Karl Fogel's landmark book:
+`Producing Open Source Software <http://www.producingoss.com/>`_.
+
+
+The need for Collaborative Development Environments
+---------------------------------------------------
+
+An intelligent toolset is also important for tracking and managing
+community information and workflows. These tools are called
+Collaborative Development Environments (CDEs). These toolsets are
+typically web-based and manage things such as announcements,
+issues/bugs, questions and answers, downloads, documents and
+source code. Some examples of CDEs include
+`Launchpad <https://launchpad.net>`_,
+`SourceForge <http://sourceforge.net>`_,
+`java.net <http://java.net>`_ and
+`SAP Community Network <https://www.sdn.sap.com/irj/sdn>`_.
+
+
+Helping communities work with related communities
+-------------------------------------------------
+
+Many successful products have a huge number of downstream dependencies.
+In other words, a new challenge arises with success: dealing with other
+communities and understanding how your changes will impact them. This is
+most obvious for projects like:
+
+* software languages, e.g. Python, PHP, Ruby, Java, Perl, etc.
+* compilers, e.g. gcc, JDK, etc.
+* libraries, e.g. zlib, openssl, etc.
+* frameworks, e.g. Zope, Ruby on Rails, Spring, etc.
+
+However it applies equally for popular applications on which add-ons are
+built, e.g. Firefox, Thunderbird, OpenOffice.org, Drupal, Wordpress, Joomla,
+etc.
+
+Tools that assist communities work together to track and manage
+issues and fixes across community boundaries are required. These
+tools help people at both ends of the spectrum:
+
+* users can report problems in their terms, e.g. rendering of image
+ type X is broken in application Y on operating system Z
+
+* developers can better appreciate the downstream impact of making a
+ change or fix, e.g. fixing this bug in a graphics library will
+ make the users of these 5 applications on these 10 operating
+ systems happy.
+
+People in the middle play the essential role of *joining the dots* and
+communicating up and down the line. In many cases, they may also fix the
+problem for end users, releasing a patch and pushing a suggested fix
+to the upstream development team. Keeping track of all that over time
+in a sustainable way is no easy task.
+
+
+Launchpad: More development, less friction
+------------------------------------------
+
+As well as sponsoring `Ubuntu <http://www.ubuntu.com>`_ and
+`Bazaar <http://bazaar.canonical.com>`_ development, Canonical
+provides Launchpad, <https://launchpad.net/>, as a free service
+for the community. Launchpad is one of the most
+exciting CDEs around for several notable reasons:
+
+* it models relationships between many of things tracked, e.g.
+ source code branches can be associated with bug fixes
+
+* as well as managing historical knowledge,
+ it supports future development planning and tracking by providing
+ features such as roadmaps, milestones and blueprints
+
+* it provides translation tools and packaging services so that
+ barriers are reduced for translators and testers wishing to
+ join your community and help out
+
+* it provides a nexus for different communities to work
+ together on related issues and roadmaps.
+
+In other words, Launchpad has been designed to help your
+community grow and to reduce the workflow friction both
+*within* your community and *between* communities. Ultimately,
+that means less time on mechanical tasks and more time for
+interesting development.
+
+
+Bazaar: Launchpad's VCS client
+------------------------------
+
+This tutorial looks at how Bazaar and Launchpad can be used together
+and how they complement each other. It is important to remember that:
+
+1. Bazaar can be used without Launchpad
+2. Launchpad can be used without Bazaar.
+
+By design though, their sum is greater than the individual
+parts.
+
+
+Finding and browsing branches using Launchpad
+=============================================
+
+Finding available branches
+--------------------------
+
+While there are many advantages in adopting distributed version
+control, one of the things that disappears is the all-knowing
+central server with knowledge about all available branches. Indeed
+in a distributed environment, interesting branches can literally
+exist in 100s of locations across the Internet (or within an
+Intranet for that matter).
+
+Launchpad fills this gap by providing a registry of branches.
+
+
+Registering branches
+--------------------
+
+Branches can be uploaded to Launchpad or simply registered
+as being available in an external location. Branches can also
+be given a Status such as *New*, *Development*, *Mature* or
+*Abandoned*.
+
+Note: External branches can even be hosted in legacy version control
+tools, i.e. CVS and Subversion. Code in these systems will be
+scanned and converted to Bazaar branches on a periodic basis.
+For maximum fidelity of course, it is preferable for external
+branches to be hosted in Bazaar.
+
+
+Browsing branches
+-----------------
+
+Branches can be listed, filtered and sorted by numerous
+attributes including Name, Registrant, Author, Status, Age and
+time of last commit. Browsing of branches is also provided making
+it easy to see things such as:
+
+* where the branch can be downloaded from
+* how to upload changes
+* recent commits and the changes made by each
+* the source code of individual files for a given version.
+
+
+Accessing code in Launchpad using Bazaar
+========================================
+
+Getting the code for a project
+------------------------------
+
+As Launchpad keeps track of thousands of projects
+and their latest code whether it be managed by Bazaar, CVS or Subversion,
+Bazaar users can grab that code as easily as this::
+
+ bzr branch lp:project-name
+
+where `project-name` is the Launchpad project ID. Here are some examples::
+
+ bzr branch lp:inkscape
+ bzr branch lp:amarok
+ bzr branch lp:python
+ bzr branch lp:rails
+ bzr branch lp:java-gnome
+
+You can then browse the code locally using your favorite editor or IDE and
+change the code if you wish.
+
+If a project has multiple series registered (e.g. a development series and a
+maintenance series), the latest code for a given series can be fetched using::
+
+ bzr branch lp:project-name/series
+
+Publishing your changes
+-----------------------
+
+Having fixed that annoying bug or added that cool feature you've always
+wanted, it's time to impress your friends and make the world a better
+place by making your code available to others. As explained earlier,
+Launchpad is a free Bazaar code hosting service so you can push your
+branch to it and others can access your code from there. For example,
+assuming you are a member of the relevant team, login to launchpad like this::
+
+ bzr launchpad-login userid
+
+where `userid` is your Launchpad user ID.
+You can then push your changes to a team branch like this::
+
+ bzr push lp:~team-name/project-name/branch-name
+
+Others can then download your code like this::
+
+ bzr branch lp:~team-name/project-name/branch-name
+
+
+Personal branches
+-----------------
+
+Even if you are not a member of a team, Launchpad can be used to publish
+your changes. In this case, simply create a personal branch like this::
+
+ bzr push lp:~userid/project-name/branch-name
+
+Others can then download your code like this::
+
+ bzr branch lp:~userid/project-name/branch-name
+
+Note: Even when publishing to a personal branch, it is polite to notify the
+upstream developers about your branch so they can pull your changes from
+it if they are generally applicable to all users and meet the project's
+quality standards.
+
+
+Package source branches
+-----------------------
+
+When `maintaining packages for Ubuntu using Bazaar`_ you can easily access the
+package's source branch on Launchpad. The package's source branch in the
+current (default) series can be downloaded like this::
+
+ bzr branch ubuntu:package
+
+where *package* is the name of the Ubuntu package you want to access. To
+download the package branch for a specific series in Ubuntu (e.g. Maverick or
+Lucid), use this::
+
+ bzr branch ubuntu:maverick/package
+
+Ubuntu distroseries can also be abbreviated to just their first letter. For
+example, the above could also be written::
+
+ bzr branch ubuntu:m/package
+
+You can also download the package source branch from Launchpad for several
+Debian series. The default series can be downloaded like this::
+
+ bzr branch debianlp:package
+
+and a specific series can be downloaded like this::
+
+ bzr branch debianlp:lenny/package
+
+Note that the ``debianlp:`` scheme access the Debian source branch for a
+package from Launchpad only.
+
+.. _`maintaining packages for Ubuntu using Bazaar`: https://wiki.ubuntu.com/DistributedDevelopment
+
+
+Linking branches using Launchpad
+================================
+
+Associating a branch with a bug
+-------------------------------
+
+After registering a branch, you can associate it to a bug so that
+people interested in that bug can track and download the fix as
+it becomes available.
+
+To do this, the steps are:
+
+1. Navigate to the bug in question.
+
+2. Select `Add branch` under `Actions`.
+
+3. Select the branch.
+
+4. Optionally set the State of the relationship. This is
+ *Fix In Progress* by default but you may wish to set it
+ to another state such as *Fix Available* if the branch already
+ addresses the issue.
+
+If you wish, you can also provide some arbitrary comments about
+the relationship between the bug and the branch.
+
+
+Changing the state in Launchpad while committing in Bazaar
+----------------------------------------------------------
+
+Bazaar and Launchpad can work together to reduce some of
+the status housekeeping for you. When you commit using Bazaar,
+use the --fixes option like this::
+
+ bzr commit --fixes lp:1234 -m "..."
+
+where 1234 is the bug ID. This will changes the State of the
+bug-branch relationship to *Fix Available*. If the one commit
+fixes multiple issues, the --fixes option can be specified multiple
+times.
+
+One of the cool things about this feature is that Launchpad does
+not need to be accessible when making the commit. The ``--fixes``
+option works by storing metadata which Launchpad will detect next
+time the branch is pushed to it or scanned once online again.
+
+Note: Launchpad will not implicitly close a bug just because a
+branch is available that fixes it. There are several reasons for this.
+Firstly, the branch usually needs to be merged into the trunk
+(main development branch) before most teams consider it fixed.
+Secondly, many teams have a separate process for confirming
+bugs are fixed over and above a developer saying so.
+
+As explained later, merge control features are currently under
+development in Launchpad and automatically changing the status of
+bugs to *Fix Committed* will be more appropriate once those features
+are in place.
+
+
+Associating a branch with a blueprint
+-------------------------------------
+
+After registering a branch, you can associate it to a blueprint so that
+people interested in that blueprint can track and test the feature as
+it develops.
+
+To do this, the steps are:
+
+1. Navigate to the blueprint in question.
+
+2. Select `Link branch` under `Actions`.
+
+3. Select the branch.
+
+If you wish, you can also provide some arbitrary comments about
+the relationship between the blueprint and the branch.
+
+
+Managing releases using Launchpad
+=================================
+
+Integrating changes
+-------------------
+
+Once a branch has been developed and published, communities
+typically go through a rigorous process before those changes
+are integrated into the core product and rolled out to end users.
+Some of the steps involved may include:
+
+* peer review of the changes
+
+* deciding which releases to include the changes in, e.g. the
+ next maintenance release, the next major release, or both
+
+* running functional regression tests
+
+* benchmarking to ensure performance remains acceptable
+
+* packaging into early access releases for end user testing
+
+* documentation updates, e.g. Release Notes for the targeted
+ releases
+
+* translation of the user interface and documentation into
+ multiple languages.
+
+This section briefly looks at some of the features in Launchpad that
+help get good quality code into production. Strong integration with
+Bazaar is core to making this happen smoothly.
+
+Note: Where indicated, some of the features below are still under
+development. If one or more of these features interest you, please
+consider joining the Launchpad beta test team at this link:
+https://help.launchpad.net/JoiningLaunchpadBetaTesters. You can
+then get early access to features and provide feedback to the
+developers before wider roll-out.
+
+
+Branch merge proposals
+----------------------
+
+After navigating to a branch in Launchpad, one of the available actions
+is *Propose for merging*. This lets you nominate which branch this code
+ought to be merged into.
+
+Tracking the knowledge about which branches are proposed to be merged
+into a codeline helps Release Managers keep on top of what still needs
+to be completed, or can be completed, before a ship date. Using this
+information, they can ensure branches are merged after completing any
+necessary reviews. In the simple case, the Release Manager may manually
+merge branches. In more advanced cases, the merging could be automatically
+done by a robot (like `PQM`_) when the branch reaches the right state
+(e.g. *Review completed*).
+
+.. _PQM: https://launchpad.net/pqm
+
+
+Code review tracking
+--------------------
+
+A number of features are under development in Launchpad to track the
+states, conversations and outcomes of code reviews. These features are
+expected to be integrated with branch merge proposals and branch
+browsing features.
+
+
+Personal Package Archives (PPAs)
+--------------------------------
+
+PPAs help developers and development teams get custom builds into the
+hands of users for early testing and feedback. In other words, a PPA
+allows a developer to form a community of testers who are interested
+in their changes. The testing community can install the packages,
+run them for the test period and then remove them cleanly from their
+system.
+
+See https://help.launchpad.net/PPAQuickStart for further details.
+
+
+Translations
+------------
+
+The Translations module in Launchpad is designed to make it easy for
+anyone to get involved translating applications to languages they know.
+Translators are shielded from the low level details.
+
+Launchpad keeps track of the translations for each major version of a
+project separately, allowing translators to continue to improve the
+translations of your stable releases while others start work on newer
+versions that are still in development. Translation speed in reduced
+by sharing resources across projects. Automatic suggestions, from a
+library of 750,000 translated strings, and a community of 19,000
+registered translators can radically cut the time required to
+localise your project into many languages.
+
+
+Summary
+=======
+
+The communities we join, whether off-line or on-line,
+say a lot about the sort of people we are. The flip-side
+to this is that the tools you choose for your community - particularly
+the CDE and version control tool - can have a large impact on who
+joins and how easily they can contribute.
+
+In their own right, Launchpad and Bazaar are highly useful tools.
+Together, they can:
+
+* help your community track major assets such as source code and knowledge
+* help it grow by reducing barriers to entry
+* help it interact with related communities.
+
+In particular, Launchpad is a free code hosting service for your Bazaar
+branches, branches can be browsed online, branches can be linked to bugs
+and blueprints, and the status of bug-branch relationships can be
+automatically managed by mentioning the bug while committing in Bazaar.
+Further integration is under development with the aim of streamlining
+the process from *great idea* to *running code in the hands of end users*.
+
+If you have any feedback on how you'd like to see Bazaar and Launchpad
+further integrated, please contact us on the Bazaar mailing list,
+bazaar@lists.canonical.com.
+
+While designed as a free service to support free software projects,
+Canonical may make Launchpad available to commercial software developers
+depending on their requirements. We would be happy to hear from you
+if you think Launchpad would be useful for managing your community.
diff --git a/doc/en/upgrade-guide/data_migration.txt b/doc/en/upgrade-guide/data_migration.txt
new file mode 100644
index 0000000..e414356
--- /dev/null
+++ b/doc/en/upgrade-guide/data_migration.txt
@@ -0,0 +1,217 @@
+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 running **upgrade**.
+
+For detailed help on these commands, see the `Bazaar User Reference`_.
+
+.. _Bazaar User Reference: ../user-reference/index.html
+
+
+Communicating with your community
+---------------------------------
+
+To enable a smooth transition 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
+-------------------------------
+
+You have two options for upgrading your Launchpad branches. You can either
+upgrade them remotely or you can upgrade them locally and push the migrated
+branch to Launchpad. We recommend the latter. Upgrading remotely currently
+requires a fast, rock solid network connection to the Launchpad servers, and
+any interruption in that connection can leave you with a partially upgraded
+branch. The instructions below are the safest and often fastest way to
+upgrade your Launchpad branches.
+
+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.
+
+In Launchpad, a project can define a *development series* and associate a
+branch with that series. The branch then becomes the *focus of development*
+and gets special treatment and a shortcut URL. By default, if anybody
+branches your project's focus of development and pushes changes back to
+Launchpad, their branch will be stacked on your development focus branch.
+Also, branches can be associated with other Launchpad artifacts such as bugs
+and merge proposals. All of these things mean that upgrading your focus of
+development branch is trickier.
+
+Here are the steps to follow:
+
+1. The nominated person grabs a copy of trunk and does the migration locally.
+
+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.)
+
+ 1. Go to your project's home page on Launchpad
+
+ 2. Look for "XXX is the current focus of development"
+
+ 3. Click on the edit (pencil) icon
+
+ 4. Click on "Change details" in the portlet on the right
+
+ 5. Scroll down to where it says "Branch: (Optional)"
+
+ 6. Blank out this input field and click "Change"
+
+3. Push the migrated trunk to Launchpad. See below if you want your
+ new migrated development focus branch to have the same name as your old
+ pre-migration development focus branch.
+
+4. Set it as the development focus. Follow the instructions above but at step
+ 5, enter the name of the newly migrated branch you just pushed.
+
+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.
+
+If you want your new migrated development focus branch to have the same name
+as your old pre-migration branch, you need to do a few extra things before you
+establish the new development focus.
+
+1. Rename your old pre-migration branch; use something like
+ **foo-obsolete-do-not-use**. You will really not want to delete this
+ because there will be artifacts (bugs, merge proposals, etc.) associated
+ with it.
+
+2. Rename the new migrated branch to the pre-migration branch's old name.
+
+3. Re-establish the development focus branch using the new migrated branch's
+ new name (i.e. the old pre-migration branch's original name).
+
+
+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 update
+the ``parent_location`` configuration variable in the ``branch.conf`` file
+with::
+
+ bzr config parent_location=XXX
+
+``XXX`` being the URL to your new trunk.
+
+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.
diff --git a/doc/en/upgrade-guide/index.txt b/doc/en/upgrade-guide/index.txt
new file mode 100644
index 0000000..e79a809
--- /dev/null
+++ b/doc/en/upgrade-guide/index.txt
@@ -0,0 +1,15 @@
+####################
+Bazaar Upgrade Guide
+####################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+.. include:: overview.txt
+.. include:: data_migration.txt
+.. include:: tips_and_tricks.txt
+.. include:: licence.txt
+
diff --git a/doc/en/upgrade-guide/licence.txt b/doc/en/upgrade-guide/licence.txt
new file mode 100644
index 0000000..09af80e
--- /dev/null
+++ b/doc/en/upgrade-guide/licence.txt
@@ -0,0 +1,7 @@
+Licence
+===============
+
+Copyright 2009-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
diff --git a/doc/en/upgrade-guide/overview.txt b/doc/en/upgrade-guide/overview.txt
new file mode 100644
index 0000000..4b2060b
--- /dev/null
+++ b/doc/en/upgrade-guide/overview.txt
@@ -0,0 +1,85 @@
+Overview
+########
+
+High level upgrade process
+--------------------------
+
+In broad terms, there are 3 steps involved in upgrading a new format:
+
+1. Upgrade the core software
+
+2. Upgrade required plugins
+
+3. Migrate data to the new default format.
+
+Bazaar supports branches in earlier formats so the third step is strictly not
+required. However, when new default formats are introduced, they are more
+space efficient, faster on large projects and/or provide new features. So it
+is recommended that most projects migrate to it at a convenient time.
+
+For most users, upgrading and migrating to the new format is straight
+forward. For projects with a large community of developers though, things
+become more complex. In these cases, careful planning and good communications
+become essential. This document provides general advice which aims to assist
+in this regard. If in doubt, please contact us on our mailing list or IRC
+channel with any questions or concerns you have.
+
+
+Upgrading the core software
+---------------------------
+
+The steps required to upgrade the core software vary from operating system to
+operating system. A brief outline of the steps is given below.
+
+To upgrade Bazaar on Ubuntu:
+
+1. Ensure your package manager is configured with the required software
+ sources, e.g. the official stable release PPA for Ubuntu:
+ https://launchpad.net/~bzr/+archive
+
+2. Use your package manager to upgrade to the latest version.
+
+To upgrade Bazaar on Windows:
+
+1. Uninstall the existing version using Add/Remove Programs.
+
+2. Install the new version using the relevant installer.
+
+To upgrade Bazaar on OS X (via the installer):
+
+1. Install the new version using the relevant installer.
+
+To upgrade Bazaar on OS X (via MacPorts):
+
+1. Refresh the package metadata using **sudo port selfupdate**
+
+2. Upgrade to the latest version using **sudo port upgrade bzr**
+
+For further information on installing and upgrading, see
+http://wiki.bazaar.canonical.com/Download.
+
+
+Upgrading required plugins
+--------------------------
+
+Many plugins are not dependent on a particular Bazaar version so
+upgrading them is optional. Other plugins, notably bzrtools and
+bzr-svn, are more tightly associated with Bazaar's APIs so these
+typically need to be upgraded in lockstep with the core software.
+
+For Windows and OS X users, bzrtools and bzr-svn are typically included in
+the installer so no special steps are required to upgrade these. For
+Ubuntu and other GNU/Linux or Unix systems users, bztrools, bzr-svn and
+many other popular plugins can be installed and upgraded using your
+platform's package manager, e.g. Synaptic on Ubuntu.
+
+
+Migrating data to the new default format
+----------------------------------------
+
+As mentioned earlier, the complexity of migrating to a new format
+depends on several factors, particularly project community size.
+It also depends on how data is currently stored, e.g. in a
+standalone branch, multiple branches in a shared repository,
+stacked branches on Launchpad, etc. These various scenarios are
+covered in the next chapter.
diff --git a/doc/en/upgrade-guide/tips_and_tricks.txt b/doc/en/upgrade-guide/tips_and_tricks.txt
new file mode 100644
index 0000000..4f6a68d
--- /dev/null
+++ b/doc/en/upgrade-guide/tips_and_tricks.txt
@@ -0,0 +1,35 @@
+Tips and tricks
+###############
+
+Finding obsolete branches
+-------------------------
+
+If you use feature branching for developing each fix
+and enhancement separately, you may have several old
+branches that are no longer required. In many cases,
+the relevant changes may now be merged into trunk.
+In other cases, a branch may be obsolete thanks to
+another change made by yourself or others.
+
+When checking for an obsolete branch, there are three
+things in particular to confirm:
+
+1. The working tree has no in-progress changes.
+
+2. The working tree has no shelved changes.
+
+3. Any locally committed revisions have been merged
+ into the parent branch.
+
+After changing into the root of a branch, the commands
+to check these things respectively are::
+
+ bzr status
+ bzr shelve --list
+ bzr missing --mine-only
+
+If your branches are stored in a shared repository locally,
+you may find the *Local Changes* tab in Bazaar Explorer's
+repository view helpful here (revision 159 or later) as it
+shows a summary of these things, excluding the shelve information
+currently, for each branch as you select it.
diff --git a/doc/en/user-guide/adv_merging.txt b/doc/en/user-guide/adv_merging.txt
new file mode 100644
index 0000000..e592ad4
--- /dev/null
+++ b/doc/en/user-guide/adv_merging.txt
@@ -0,0 +1,136 @@
+Pseudo merging
+==============
+
+Cherrypicking
+-------------
+
+At times, it can be useful to selectively merge some of the changes
+in a branch, but not all of them. This is commonly referred to as
+*cherrypicking*. Here are some examples of where cherrypicking is
+useful:
+
+* selectively taking fixes from the main development branch into
+ a release branch
+
+* selectively taking improvements out of an experimental branch into
+ a feature branch.
+
+To merge only the changes made by revision X in branch ``foo``,
+the command is::
+
+ bzr merge -c X foo
+
+To merge only the changes up to revision X in branch ``foo``,
+the command is::
+
+ bzr merge -r X foo
+
+To merge only the changes since revision X in branch ``foo``,
+the command is::
+
+ bzr merge -r X.. foo
+
+To merge only the changes from revision X to revision Y in branch ``foo``,
+the command is::
+
+ bzr merge -r X..Y foo
+
+Like a normal merge, you must explicitly commit a cherrypick. You may wish
+to see the changes made using ``bzr diff``, and run your test suite if any,
+before doing this.
+
+Unlike a normal merge, Bazaar does not currently track cherrypicks.
+In particular, the changes look like a normal commit and the (internal)
+revision history of the changes from the other branch is lost.
+In many cases where they are useful (see above), this is not a major
+problem because there are good reasons why a full merge should never
+be done at a later time. In other cases, additional conflicts will need
+to be resolved when the changes are merged again.
+
+Merging without parents
+-----------------------
+
+A related technique to cherrypicking, in that it makes changes without
+reference to the revisions that they came from is to perform a merge, but
+forget about the parent revisions before committing. This has the effect of
+making all of the changes that would have been in the merge happen in a single
+commit. After the merge and before the corresponding commit, you can do::
+
+ bzr revert --forget-merges
+
+to keep the changes in the working tree, but remove the record of the
+revisions where the changes originated. The next commit would then record
+all of those changes without any record of the merged revisions.
+
+This is desired by some users to make their history "cleaner", but you should
+be careful that the loss of history does not outweigh the value of cleanliness,
+particularly given Bazaar's capabilities for progressively disclosing merged
+revisions. In particular, because this will include the changes from the
+source branch, but without attribution to that branch, it can lead to
+additional conflicts on later merges that involve the same source and
+target branches.
+
+
+Reverse cherrypicking
+---------------------
+
+Cherrypicking can be used to reverse a set of changes made by giving an
+upper bound in the revision range which is *below* the lower bound.
+For example, to back-out changes made in revision 10, the command is::
+
+ bzr merge -r 10..9
+
+If you want to take most changes, but not all, from somewhere else, you
+may wish to do a normal merge followed by a few reverse cherrypicks.
+
+
+Merging uncommitted changes
+---------------------------
+
+If you have several branches and you accidentally start making changes in the
+wrong one, here are the steps to take to correct this. Assuming you began
+working in branch ``foo`` when you meant to work in branch ``bar``:
+
+1. Change into branch ``bar``.
+2. Run ``bzr merge --uncommitted foo``
+3. Check the changes came across (``bzr diff``)
+4. Change into branch ``foo``
+5. Run ``bzr revert``.
+
+.. TODO Selective file merging?
+
+
+Rebasing
+--------
+
+Another option to normal merging is *rebasing*, i.e. making it look like
+the current branch originated from a different point than it did.
+Rebasing is supported in Bazaar by the ``rebase`` command provided by
+the ``rebase`` plugin.
+
+The ``rebase`` command takes the location of another branch on which
+the branch in the current working directory will be rebased. If a branch
+is not specified then the parent branch is used, and this is usually the
+desired result.
+
+The first step identifies the revisions that are in the current branch
+that are not in the parent branch. The current branch is then set to be
+at the same revision as the target branch, and each revision is replayed
+on top of the branch. At the end of the process it will appear as though
+your current branch was branched off the current last revision of the target.
+
+Each revision that is replayed may cause conflicts in the tree. If this
+happens the command will stop and allow you to fix them up. Resolve the
+commits as you would for a ``merge``, and then run ``bzr resolve`` to
+marked them as resolved. Once you have resolved all the conflicts, you
+should run ``bzr rebase-continue`` to continue the rebase operation.
+If conflicts are encountered and you decide not to continue,
+you can run ``bzr rebase-abort``. You can also use ``rebase-todo`` to
+show the list of commits still to be replayed.
+
+Note: Some users coming from central VCS tools with poor merge tracking
+like rebasing because it's similar to how they are use to working in older
+tools, or because "perfectly clean" history seems important. Before rebasing
+in Bazaar, think about whether a normal merge is a better choice. In
+particular, rebasing a private branch before sharing it is OK but
+rebasing after sharing a branch with someone else is **strongly** discouraged.
diff --git a/doc/en/user-guide/annotating_changes.txt b/doc/en/user-guide/annotating_changes.txt
new file mode 100644
index 0000000..0c2aaad
--- /dev/null
+++ b/doc/en/user-guide/annotating_changes.txt
@@ -0,0 +1,35 @@
+Annotating changes
+==================
+
+Seeing the origin of content
+----------------------------
+
+When two or more people are working on files, it can be highly
+useful at times to see who created or last changed certain content.
+To do this, using the annotate command like this::
+
+ bzr annotate readme.txt
+
+If you are a pessimist or an optimist, you might prefer to use
+one of built-in aliases for ``annotate``: ``blame`` or ``praise``.
+Either way, this displays each line of the file together with
+information such as:
+
+ * who changed it last
+ * when it was last changed
+ * the commit message.
+
+GUI tools
+---------
+
+The various GUI plugins for Bazaar provide graphical tools for
+viewing annotation information. For example, the bzr-gtk plugin
+provides a GUI tool for this that can be launched using the
+``gannotate`` command::
+
+ bzr gannotate readme.txt
+
+The GUI tools typically provide a much richer display of
+interesting information (e.g. all the changes in each commit)
+so you may prefer them over the text-based command.
+
diff --git a/doc/en/user-guide/bazaar_workflows.txt b/doc/en/user-guide/bazaar_workflows.txt
new file mode 100644
index 0000000..38e95b2
--- /dev/null
+++ b/doc/en/user-guide/bazaar_workflows.txt
@@ -0,0 +1,171 @@
+Workflows
+=========
+
+Bazaar is just a tool
+---------------------
+
+Bazaar supports many different ways of working together.
+This means that you can
+start with one workflow and adapt it over time as circumstances
+change. There is no "one true way" that always makes sense and
+there never will be. This section provides a brief overview of
+some popular workflows supported by Bazaar.
+
+Keep in mind that these workflow are just *some* examples of how
+Bazaar can be used. You may want to use a workflow not listed here,
+perhaps building on the ideas below.
+
+Solo
+----
+
+Whether developing software, editing documents or changing configuration files,
+having an easy-to-use VCS tool can help. A single user can use this workflow
+effectively for managing projects where they are the only contributor.
+
+.. image:: images/workflows_single.png
+
+Advantages of this workflow over not using version control at all include:
+
+ * backup of old versions
+ * rollback to an earlier state
+ * tracking of history.
+
+The key features of Bazaar appropriate for this workflow are low administration
+(no server setup) and ease of use.
+
+
+Partner
+-------
+
+Sometimes two people need to work together sharing changes as they go. This
+commonly starts off as a *Solo* workflow (see above) or a team-oriented
+workflow (see below). At some point, the second person takes a branch (copy
+including history) of what the first person has done. They can then work in
+parallel exchanging changes by merging when appropriate.
+
+.. image:: images/workflows_peer.png
+
+Advantages over *Solo* are:
+
+ * easier sharing of changes
+ * each line of each text file can be attributed to a particular change
+ including who changed it, when and why.
+
+When implementing this workflow, Bazaar's advantages over CVS and Subversion include:
+
+ * no server to setup
+ * intelligent merging means merging multiple times isn't painful.
+
+
+Centralized
+-----------
+
+Also known as *lock-step*, this is essentially the same as the workflow
+encouraged/enforced by CVS and Subversion. All developers work on the same
+branch (or branches). They run ``bzr update`` to get their checkout up-to-date,
+then ``bzr commit`` to publish their changes to the central location.
+
+.. image:: images/workflows_centralized.png
+
+Subversion and CVS are good choices for implementing this workflow because they
+make it easy. Bazaar directly supports it as well while providing some
+important advantages over CVS and Subversion:
+
+ * better branching and merging
+ * better renaming support.
+
+
+Centralized with local commits
+------------------------------
+
+This is essentially the same as the *Centralized* model, except that when
+developers are making a series of changes, they do ``commit --local`` or unbind
+their checkout. When it is complete, they commit their work to the shared
+mainline.
+
+.. image:: images/workflows_localcommit.png
+
+Advantages over *Centralized*:
+
+ * Can work offline, e.g. when disconnected during travel
+ * Less chance for a bad commit to interfere with everyone else's work
+
+Subversion and CVS do not support this model. Other distributed VCS tools can
+support it but do so less directly than Bazaar does.
+
+
+Decentralized with shared mainline
+----------------------------------
+
+In this workflow, each developer has their own branch or branches, plus commit
+rights to the main branch. They do their work in their personal branch, then
+merge it into the mainline when it is ready.
+
+.. image:: images/workflows_shared.png
+
+Advantage over *Centralized with local commits*:
+
+ * Easier organization of work - separate changes can be developed in their own branches
+ * Developers can merge one another's personal branches when working on something together.
+
+Subversion and CVS do not support this model. Other distributed VCS
+tools support it. Many features of Bazaar are good for this workflow
+including ease of use, shared repositories, integrated merging and
+rich metadata (including directory rename tracking).
+
+
+Decentralized with human gatekeeper
+-----------------------------------
+
+In this workflow, each developer has their own branch or branches, plus
+read-only access to the main branch. One developer (the gatekeeper) has commit
+rights to the main branch. When a developer wants their work merged, they ask
+the gatekeeper to merge it. The gatekeeper does code review, and merges the
+work into the main branch if it meets the necessary standards.
+
+.. image:: images/workflows_gatekeeper.png
+
+Advantage over *Decentralized with shared mainline*:
+
+ * Code is always reviewed before it enters the mainline
+ * Tighter control over when changes get incorporated into the mainline.
+
+A companion tool of Bazaar's called Bundle Buggy can be very useful for
+tracking what changes are up for review, their status and reviewer comments.
+
+
+Decentralized with automatic gatekeeper
+---------------------------------------
+
+In this workflow, each developer has their own branch or branches, plus
+read-only access to the mainline. A software gatekeeper has commit rights to
+the main branch. When a developer wants their work merged, they request another
+person to review it. Once it has passed review, either the original author or
+the reviewer asks the gatekeeper software to merge it, depending on team
+policies. The gatekeeper software does a merge, a compile, and runs the test
+suite. If and only if the code passes, it is merged into the mainline.
+
+Note: As an alternative, the review step can be skipped and the author can
+submit the change to the automatic gatekeeper without it. (This is particularly
+appropriate when using practices such as Pair Programming that effectively
+promote just-in-time reviews instead of reviewing code as a separate step.)
+
+.. image:: images/workflows_pqm.png
+
+Advantages over *Decentralized with human gatekeeper*:
+
+ * Code is always tested before it enters the mainline (so the integrity of the
+ mainline is higher)
+ * Scales better as teams grow.
+
+A companion tool of Bazaar's called Patch Queue Manager (PQM) can provide the
+automated gatekeeper capability.
+
+
+Implementing a workflow
+-----------------------
+
+For an in-depth look at how to implement each of the workflows above,
+see chapters 3 to 6 in this manual. First though, chapter 2
+explains some important pre-requisites including installation, general
+usage instructions and configuration tips.
diff --git a/doc/en/user-guide/branching_a_project.txt b/doc/en/user-guide/branching_a_project.txt
new file mode 100644
index 0000000..7c93bee
--- /dev/null
+++ b/doc/en/user-guide/branching_a_project.txt
@@ -0,0 +1,129 @@
+Branching a project
+===================
+
+Branch URLs
+-----------
+
+Before someone else can get a copy of your work, you need to
+agree on a transfer technology.
+You may decide to make the top level directory of your branch
+a network share, an approach familiar to Windows users.
+Unix users might prefer access to be
+via SSH, a secure protocol built-in to most SSH servers.
+Bazaar is *very* flexible in this regard with support for
+lots of protocols some of which are given below.
+
+ =========== ======================================================
+ Prefix Description
+ =========== ======================================================
+ \file:// Access using the standard filesystem (default).
+ \bzr+ssh:/ Access over SSH (best remote option).
+ \sftp:// Access using SFTP (most SSH servers provide SFTP).
+ \bzr:// Fast access using the Bazaar smart server.
+ \ftp:// Access using passive FTP.
+ \http:// Access to branches exported by a web server.
+ \https:// Encrypted access to branches exported by a web server.
+ =========== ======================================================
+
+As indicated above, branches are identified using URLs with the
+prefix indicating the transfer technology. If no prefix is given,
+normal filenames are assumed. For a complete list of supported
+protocols, see the ``urlspec`` online help topic or the
+`URL Identifiers <../user-reference/index.html#url-identifiers>`_
+section of the Bazaar User Reference.
+
+URLs are normally resolved relative to the root directory of the server,
+so ``ftp://example.com/repo/foo`` means the ``/repo/foo`` directory of
+that host. (We say 'normally' because some server software like Apache
+can be configured to remap URLs arbitrarily, in which case you'll need to
+look at the server configuration to find out which URL corresponds to
+which directory.)
+
+To address a path relative to your home directory on the server, use a
+tilde like so: ``bzr+ssh://example.com/~/public_html`` should map to
+``public_html`` within your home directory.
+
+.. note:: Access over HTTP or HTTPS is read-only by default.
+ See `Pushing over the HTTP smart server
+ <http_smart_server.html#pushing-over-the-http-smart-server>`_ for
+ details on configuring read-write access.
+
+A reminder about shared repositories
+------------------------------------
+
+Before getting a copy of a branch, have a quick think about
+where to put it on your filesystem. For maximum storage
+efficiency down the track, it is recommended that branches
+be created somewhere under a directory that has been set up
+as a shared repository. (See `Feature branches
+<organizing_your_workspace.html#feature-branches>`_ in
+`Organizing your workspace <organizing_your_workspace.html>`_
+for a commonly used layout.) For example::
+
+ bzr init-repo my-repo
+ cd my-repo
+
+You are now ready to grab a branch from someone else and
+hack away.
+
+The branch command
+------------------
+
+To get a branch based on an existing branch, use the ``branch`` command.
+The syntax is::
+
+ bzr branch URL [directory]
+
+If a directory is not given, one is created based on the last part of
+the URL. Here are some examples showing a drive qualified path (M:/) and an
+SFTP URL respectively::
+
+ bzr branch M:/cool-trunk
+ bzr branch sftp://bill@mary-laptop/cool-repo/cool-trunk
+
+This example shows explicitly giving the directory name to use for the
+new branch::
+
+ bzr branch /home/mary/cool-repo/cool-trunk cool
+
+Time and space considerations
+-----------------------------
+
+Depending on the size of the branch being transferred and the
+speed and latency of the network between your computer and the
+source branch, this initial transfer might take some time.
+Subsequent updates should be much faster as only the
+changes are transferred then.
+
+Keep in mind that Bazaar is transferring the
+complete history of the branch, not just the latest snapshot.
+As a consequence, you can be off the network (or disconnected
+from the network share) after ``branch`` completes but you'll
+still be able to ``log`` and ``diff`` the history of the
+branch as much as you want. Furthermore, these operations
+are quick as the history is stored locally.
+
+Note that Bazaar uses smart compression technology to
+minimize the amount of disk space required to store version
+history. In many cases, the complete history of a project
+will take up less disk space than the working copy of
+the latest version.
+
+As explained in later chapters, Bazaar also has support for
+`lightweight checkouts <using_checkouts.html#getting-a-lightweight-checkout>`_
+of a branch, i.e. working trees with
+no local storage of history. Of course, disconnected usage
+is not available then but that's a tradeoff you can decide
+to make if local disk space is really tight for you. Support for
+limited lookback into history - *history horizons* - is
+currently under development as well.
+
+Viewing branch information
+--------------------------
+
+If you wish to see information about a branch including where it came from,
+use the ``info`` command. For example::
+
+ bzr info cool
+
+If no branch is given, information on the current branch is displayed.
diff --git a/doc/en/user-guide/browsing_history.txt b/doc/en/user-guide/browsing_history.txt
new file mode 100644
index 0000000..c805b1f
--- /dev/null
+++ b/doc/en/user-guide/browsing_history.txt
@@ -0,0 +1,103 @@
+Browsing history
+================
+
+bzr log
+-------
+
+The ``bzr log`` command shows a list of previous revisions.
+
+As with ``bzr diff``, ``bzr log`` supports the ``-r`` argument::
+
+ % bzr log -r 1000.. # Revision 1000 and everything after it
+ % bzr log -r ..1000 # Everything up to and including r1000
+ % bzr log -r 1000..1100 # changes from 1000 to 1100
+ % bzr log -r 1000 # The changes in only revision 1000
+
+Viewing merged revisions
+------------------------
+
+As distributed VCS tools like Bazaar make merging much easier than
+it is in central VCS tools, the history of a branch may often contain
+lines of development splitting off the mainline and merging back
+in at a later time. Technically, the relationship between the
+numerous revision nodes is known as a Directed Acyclic Graph or
+DAG for short.
+
+In many cases, you typically want to see the mainline first and drill
+down from there. The default behaviour of log is therefore to show
+the mainline and indicate which revisions have nested merged revisions.
+To explore the merged revisions for revision X, use the following command::
+
+ bzr log -n0 -rX
+
+To see all revisions and all their merged revisions::
+
+ bzr log -n0
+
+Note that the -n option is used to indicate the number of levels to display
+where 0 means all. If that is too noisy, you can easily adjust the number
+to only view down so far. For example, if your project is structured with
+a top level gatekeeper merging changes from team gatekeepers, ``bzr log``
+shows what the top level gatekeeper did while ``bzr log -n2`` shows what
+the team gatekeepers did. In the vast majority of cases though, ``-n0``
+is fine.
+
+Tuning the output
+-----------------
+
+The ``log`` command has several options that are useful for tuning
+the output. These include:
+
+ * ``--forward`` presents the log in chronological order, i.e. the
+ most recent revisions are displayed last.
+
+ * the ``--limit`` option controls the maximum number of revisions displayed.
+
+See the online help for the log command or the User Reference for more
+information on tuning the output.
+
+Viewing the history for a file
+------------------------------
+
+It is often useful to filter the history so that it only
+applies to a given file. To do this, provide the filename
+to the ``log`` command like this::
+
+ bzr log foo.py
+
+Viewing an old version of a file
+--------------------------------
+
+To get the contents of a file at a given version, use the
+``cat`` command like this::
+
+ bzr cat -r X file
+
+where ``X`` is the revision identifier and ``file`` is
+the filename. This will send output to the standard output
+stream so you'll typically want to pipe the output through
+a viewing tool (like ``less`` or ``more``) or redirect it
+like this::
+
+ bzr cat -r -2 foo.py | less
+ bzr cat -r 1 foo.py > /tmp/foo-1st-version.py
+
+Graphical history viewers
+-------------------------
+
+History browsing is one area where GUI tools really make life easier.
+Bazaar has numerous plug-ins that provide this capability including
+QBzr and bzr-gtk. See `Using plugins <plugins.html>`_ for details on how to install
+these if they are not already installed.
+
+To use the graphical viewer from QBzr::
+
+ bzr qlog
+
+To use the graphical viewer from bzr-gtk::
+
+ bzr viz
+
+``viz`` is actually a built-in alias for ``visualize`` so use the longer
+command name if you prefer.
+
diff --git a/doc/en/user-guide/bug_trackers.txt b/doc/en/user-guide/bug_trackers.txt
new file mode 100644
index 0000000..cb5df5e
--- /dev/null
+++ b/doc/en/user-guide/bug_trackers.txt
@@ -0,0 +1,56 @@
+Bug trackers
+============
+
+Bazaar has a facility that allows you to associate a commit with a bug
+in the project's bug tracker. Other tools (or hooks) can then use this
+information to generate hyperlinks between the commit and the bug, or to
+automatically mark the bug closed in the branches that contain the commit.
+
+Associating commits and bugs
+----------------------------
+
+When you make a commit, you can associate it with a bug by using the
+``--fixes`` option of ``commit``. For example::
+
+ $ bzr commit --fixes lp:12345 -m "Properly close the connection"
+
+This records metadata in Bazaar linking the commit with bug 12345 in
+Launchpad. If you use a different bug tracker, it can be given its own
+tracker code (instead of ``lp``) and used instead. For details on how
+to configure this for Bugzilla, Trac, Roundup and other bug/issue trackers,
+refer to `Bug Tracker Settings`_ in the Bazaar User Reference.
+
+.. _Bug Tracker Settings: ../user-reference/index.html#bug-tracker-settings
+
+Metadata recording vs bug tracker updating
+------------------------------------------
+
+Recording metadata about bugs fixed at commit time is only
+one of the features needed for complete bug tracker integration.
+As Bazaar is a distributed VCS, users may be offline while committing
+so accessing the bug tracker itself at that time may not be possible.
+Instead, it is recommended that a hook be installed to update
+the bug tracker when changes are pushed to a central location
+appropriate for your project's workflow.
+
+Note: This second processing stage is part of the integration provided
+by Launchpad when it scans external or hosted branches.
+
+Making corrections
+------------------
+
+This method of associating revisions and bugs does have some limitations. The
+first is that the association can only be made at commit time. This means that
+if you forget to make the association when you commit, or the bug is reported
+after you fix it, you generally cannot go back and add the link later.
+
+Related to this is the fact that the association is immutable. If a bug is
+marked as fixed by one commit but that revision does not fully solve the
+bug, or there is a later regression, you cannot go back and remove the link.
+
+Of course, ``bzr uncommit`` can always be used to undo the last commit in
+order to make it again with the correct options. This is commonly done
+to correct a bad commit message and it equally applies to correcting
+metadata recorded (via ``--fixes`` for example) on the last commit.
+
+Note: ``uncommit`` is best done before incorrect revisions become public.
diff --git a/doc/en/user-guide/bzrtools_plugin.txt b/doc/en/user-guide/bzrtools_plugin.txt
new file mode 100644
index 0000000..f079dd0
--- /dev/null
+++ b/doc/en/user-guide/bzrtools_plugin.txt
@@ -0,0 +1,33 @@
+BzrTools
+========
+
+Overview
+--------
+
+BzrTools is a collection of useful enhancements to Bazaar.
+For installation instructions, see the BzrTools home page:
+http://wiki.bazaar.canonical.com/BzrTools.
+Here is a sample of the frequently used commands it provides.
+
+
+shell
+-----
+
+``bzr shell`` starts up a command interpreter than understands
+Bazaar commands natively. This has several advantages:
+
+ * There's no need to type ``bzr`` at the front of every command.
+
+ * Intelligent auto-completion is provided.
+
+ * Commands run slightly faster as there's no need to load Bazaar's
+ libraries each time.
+
+
+cdiff
+-----
+
+``bzr cdiff`` provides a colored version of ``bzr diff`` output.
+On GNU/Linux, UNIX and OS X, this is often used like this::
+
+ bzr cdiff | less -R
diff --git a/doc/en/user-guide/central_intro.txt b/doc/en/user-guide/central_intro.txt
new file mode 100644
index 0000000..1d4b4b2
--- /dev/null
+++ b/doc/en/user-guide/central_intro.txt
@@ -0,0 +1,32 @@
+Centralized development
+=======================
+
+Motivation
+----------
+
+Rather than working in parallel and occasionally merging, it can be
+useful at times to work in lockstep, i.e. for multiple people to
+be continuously committing changes to a central location, merging
+their work with the latest content before every commit.
+
+This workflow is very familiar to users of central VCS tools like
+Subversion and CVS. It is also applicable to a single developer
+who works on multiple machines, e.g. someone who normally works
+on a desktop computer but travels with a laptop, or someone who
+uses their (Internet connected) home computer to complete office
+work out of hours.
+
+If centralized development works well for your team already, that's
+great. Many teams begin using Bazaar this way and experiment with
+alternative workflows later.
+
+Centralized workflow
+--------------------
+
+The diagram below provides an overview of the *centralized workflow*.
+
+.. image:: images/workflows_centralized.png
+
+Even if your team is planning to use a more distributed workflow, many
+of the tasks covered in this chapter may be useful to you, particularly
+how to publish branches.
diff --git a/doc/en/user-guide/configuring_bazaar.txt b/doc/en/user-guide/configuring_bazaar.txt
new file mode 100644
index 0000000..020c69c
--- /dev/null
+++ b/doc/en/user-guide/configuring_bazaar.txt
@@ -0,0 +1,167 @@
+Configuring Bazaar
+==================
+
+Telling Bazaar about yourself
+-----------------------------
+
+One function of a version control system is to keep track of who changed
+what. In a decentralized system, that requires an identifier for each
+author that is globally unique. Most people already have one of these: an
+email address. Bazaar is smart enough to automatically generate an email
+address by looking up your username and hostname. If you don't like the
+guess that Bazaar makes, then use the ``whoami`` command to set the
+identifier you want::
+
+ % bzr whoami "Your Name <email@example.com>"
+
+If ``whoami`` is used without an argument, the current value is displayed.
+
+Using a network proxy
+---------------------
+
+If your network requires that you use an HTTP proxy for outbound
+connections, you must set the ``http_proxy`` variable. If the proxy is
+also required for https connections, you need to set ``https_proxy`` too.
+If you need these and don't have them set, you may find that connections
+to Launchpad or other external servers fail or time out.
+
+On Unix you typically want to set these in ``/etc/environment`` or
+``~/.bash_profile`` and on Windows in the user profile.
+
+::
+
+ http_proxy=http://proxy.example.com:3128/
+ https_proxy=http://proxy.example.com:3128/
+
+The ``no_proxy`` variable can be set to a comma-separated list of hosts
+which shouldn't be reached by the proxy. (See
+<http://docs.python.org/library/urllib.html> for more details.)
+
+Various ways to configure
+-------------------------
+
+As shown in the example above, there are various ways to
+configure Bazaar, they all share some common properties though.
+An option has:
+
+- a name which is generally a valid python identifier,
+
+- a value which is a string. In some cases, Bazaar will be able
+ to recognize special values like 'True', 'False' to infer a
+ boolean type, but basically, as a user, you will always specify
+ a value as a string.
+
+Options are grouped in various contexts so the option name
+uniquely identifies it in this context. When needed, options can
+be made persistent by recording them in a configuration file.
+
+
+Configuration files
+-------------------
+
+Configuration files are located in ``$HOME/.bazaar`` on Unix and
+``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` on
+Windows. There are three primary configuration files in this location:
+
+* ``bazaar.conf`` describes default configuration options,
+
+* ``locations.conf`` describes configuration information for
+ specific branch locations,
+
+* ``authentication.conf`` describes credential information for
+ remote servers.
+
+Each branch can also contain a configuration file that sets values specific
+to that branch. This file is found at ``.bzr/branch/branch.conf`` within the
+branch. This file is visible to **all users of a branch**. If you wish to
+override one of the values for a branch with a setting that is specific to you,
+then you can do so in ``locations.conf``.
+
+Here is sample content of ``bazaar.conf`` after setting an email address using
+the ``whoami`` command::
+
+ [DEFAULT]
+ email = Your Name <email@example.com>
+
+For further details on the syntax and configuration settings supported, see
+`Configuration Settings <../user-reference/index.html#configuration-settings>`_
+in the Bazaar User Reference.
+
+
+Looking at the active configuration
+-----------------------------------
+
+To look at all the currently defined options, you can use the following
+command::
+
+ bzr config
+
+``bzr`` implements some rules to decide where to get the value of a
+configuration option.
+
+The current policy is to examine the existing configurations files in a
+given order for matching definitions.
+
+ * ``locations.conf`` is searched first for a section whose name matches the
+ location considered (working tree, branch or remote branch),
+
+ * the current ``branch.conf`` is searched next,
+
+ * ``bazaar.conf`` is searched next,
+
+ * finally, some options can have default values generally defined in the
+ code itself and not displayed by ``bzr config`` (see `Configuration
+ Settings <../user-reference/index.html#configuration-settings>`_).
+
+This is better understood by using ```bzr config`` with no arguments, which
+will display some output of the form::
+
+ locations:
+ post_commit_to = commits@example.com
+ news_merge_files = NEWS
+ branch:
+ parent_location = bzr+ssh://bazaar.launchpad.net/+branch/bzr/
+ nickname = config-modify
+ push_location = bzr+ssh://bazaar.launchpad.net/~vila/bzr/config-modify/
+ bazaar:
+ debug_flags = hpss,
+
+Each configuration file is associated with a given scope whose name is
+displayed before each set of defined options.
+
+Modifying the active configuration
+----------------------------------
+
+To set an option to a given value use::
+
+ bzr config opt=value
+
+To remove an option use::
+
+ bzr config --remove opt
+
+
+Rule-based preferences
+----------------------
+
+Some commands and plugins provide custom processing on files matching
+certain patterns. Per-user rule-based preferences are defined in
+``BZR_HOME/rules``.
+
+For further information on how rules are searched and the detailed syntax of
+the relevant files, see `Rules <../user-reference/index.html#rules>`_
+in the Bazaar User Reference.
+
+
+Escaping command lines
+----------------------
+
+When you give a program name or command line in configuration, you can quote
+to include special characters or whitespace. The same rules are used across
+all platforms.
+
+The rules are: strings surrounded by double-quotes are interpreted as single
+"words" even if they contain whitespace, and backslash may be used to quote
+quotation marks. For example::
+
+ BZR_EDITOR="C:\Program Files\My Editor\myeditor.exe"
diff --git a/doc/en/user-guide/controlling_registration.txt b/doc/en/user-guide/controlling_registration.txt
new file mode 100644
index 0000000..d30bf96
--- /dev/null
+++ b/doc/en/user-guide/controlling_registration.txt
@@ -0,0 +1,106 @@
+Controlling file registration
+=============================
+
+What does Bazaar track?
+-----------------------
+
+As explained earlier, ``bzr add`` finds and registers all the things in
+and under the current directory that Bazaar thinks ought to be
+version controlled. These things may be:
+
+ * files
+ * directories
+ * symbolic links.
+
+Bazaar has default rules for deciding which files are
+interesting and which ones are not. You can tune those rules as
+explained in `Ignoring files`_ below.
+
+Unlike many other VCS tools, Bazaar tracks directories as first class
+items. As a consequence, empty directories are correctly supported -
+you don't need to create a dummy file inside a directory just to
+ensure it gets tracked and included in project exports.
+
+For symbolic links, the value of the symbolic link is tracked,
+not the content of the thing the symbolic link is pointing to.
+
+Note: Support for tracking projects-within-projects ("nested trees")
+is currently under development. Please contact the Bazaar developers
+if you are interested in helping develop or test this functionality.
+
+Selective registration
+----------------------
+
+In some cases, you may want or need to explicitly nominate the things
+to register rather than leave it up to Bazaar to find things. To do this,
+simply provide paths as arguments to the ``add`` command like this::
+
+ bzr add fileX dirY/
+
+Adding a directory implicitly adds all interesting things
+underneath it.
+
+Ignoring files
+--------------
+
+Many source trees contain some files that do not need to be versioned,
+such as editor backups, object or bytecode files, and built programs. You
+can simply not add them, but then they'll always crop up as unknown files.
+You can also tell Bazaar to ignore these files by adding them to a file
+called ``.bzrignore`` at the top of the tree.
+
+This file contains a list of file wildcards (or "globs"), one per line.
+Typical contents are like this::
+
+ *.o
+ *~
+ *.tmp
+ *.py[co]
+
+If a glob contains a slash, it is matched against the whole path from the
+top of the tree; otherwise it is matched against only the filename. So
+the previous example ignores files with extension ``.o`` in all
+subdirectories, but this example ignores only ``config.h`` at the top level
+and HTML files in ``doc/``::
+
+ ./config.h
+ doc/*.html
+
+To get a list of which files are ignored and what pattern they matched,
+use ``bzr ignored``::
+
+ % bzr ignored
+ config.h ./config.h
+ configure.in~ *~
+
+Note that ignore patterns are only matched against non-versioned files,
+and control whether they are treated as "unknown" or "ignored". If a file
+is explicitly added, it remains versioned regardless of whether it matches
+an ignore pattern.
+
+The ``.bzrignore`` file should normally be versioned, so that new copies
+of the branch see the same patterns::
+
+ % bzr add .bzrignore
+ % bzr commit -m "Add ignore patterns"
+
+The command ``bzr ignore PATTERN`` can be used to easily add PATTERN to
+the ``.bzrignore file`` (creating it if necessary and registering it to
+be tracked by Bazaar). Removing and modifying patterns are done by
+directly editing the ``.bzrignore`` file.
+
+Global ignores
+--------------
+
+There are some ignored files which are not project specific, but more user
+specific. Things like editor temporary files, or personal temporary files.
+Rather than add these ignores to every project, bzr supports a global
+ignore file in ``~/.bazaar/ignore`` [#]_. It has the same syntax as the
+per-project ignore file.
+
+.. [#] On Windows, the users configuration files can be found in the
+ application data directory. So instead of ``~/.bazaar/branch.conf``
+ the configuration file can be found as:
+ ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``.
+ The same is true for ``locations.conf``, ``ignore``, and the
+ ``plugins`` directory.
diff --git a/doc/en/user-guide/core_concepts.txt b/doc/en/user-guide/core_concepts.txt
new file mode 100644
index 0000000..75149ce
--- /dev/null
+++ b/doc/en/user-guide/core_concepts.txt
@@ -0,0 +1,123 @@
+Core concepts
+=============
+
+A simple user model
+-------------------
+
+To use Bazaar you need to understand four core concepts:
+
+* **Revision** - a snapshot of the files you're working with.
+
+* **Working tree** - the directory containing your version-controlled
+ files and sub-directories.
+
+* **Branch** - an ordered set of revisions that describe the history of a
+ set of files.
+
+* **Repository** - a store of revisions.
+
+Let's look at each in more detail.
+
+Revision
+--------
+
+A revision is a *snapshot* of the state of a tree of files and directories,
+including their content and shape. A revision also has some metadata
+associated with it, including:
+
+* Who committed it
+* When it was committed
+* A commit message
+* Parent revisions from which it was derived
+
+Revisions are immutable and can be globally, uniquely identified
+by a *revision-id*. An example revision-id is::
+
+ pqm@pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz
+
+Revision-ids are generated at commit time or, for imports from other
+systems, at the time of import. While revision-ids are necessary
+for internal use and external tool integration, branch-specific
+*revision numbers* are the preferred interface for humans.
+
+Revision numbers are dotted decimal identifiers like 1, 42 and 2977.1.59
+that trace a path through the revision number graph for a branch.
+Revision numbers are generally shorter than revision-ids and,
+within a single branch, can be compared with each other to get a sense
+of their relationship. For example, revision 10 is the mainline (see below)
+revision immediately after revision 9. Revision numbers
+are generated on the fly when commands are executing, because they
+depend on which revision is the tip (i.e. most recent revision)
+in the branch.
+
+See `Specifying revisions <specifying_revisions.html>`_ in the appendices
+for a closer look at the numerous ways that revisions and ranges of
+revisions can be specified in Bazaar, and `Understanding Revision Numbers
+<zen.html#understanding-revision-numbers>`_ for a more detailed
+description of revision numbering.
+
+.. *TODO: add diagram*
+
+Working Tree
+------------
+
+A working tree is a *version-controlled directory* holding files the user
+can edit. A working tree is associated with a *branch*.
+
+Many commands use the working tree as their context, e.g. ``commit`` makes
+a new revision using the current content of files in the working tree.
+
+.. *TODO: add diagram*
+
+Branch
+------
+
+In the simplest case, a branch is an *ordered series of revisions*.
+The last revision is known as the *tip*.
+
+Branches may split apart and be *merged* back together, forming a
+*graph* of revisions. Technically, the graph shows directed relationships
+(between parent and child revisions) and there are no loops, so
+you may hear some people refer to it as a *directed acyclic graph* or DAG.
+
+If this name sounds scary, don't worry. The important things
+to remember are:
+
+* The primary line of development within the DAG is called
+ the *mainline*, *trunk*, or simply the *left hand side* (LHS).
+
+* A branch might have other lines of development and if it does,
+ these other lines of development begin at some point and end at
+ another point.
+
+.. *TODO: add diagram*
+
+Repository
+----------
+
+A repository is simply a *store of revisions*. In the simplest case,
+each branch has its own repository. In other cases, it makes sense for
+branches to share a repository in order to optimize disk usage.
+
+.. *TODO: add diagram*
+
+Putting the concepts together
+-----------------------------
+
+Once you have grasped the concepts above, the various ways of using Bazaar
+should become easier to understand. The simplest way of using Bazaar is
+to use a *standalone tree*, which has a working tree, branch, and repository
+all in a single location. Other common scenarios include:
+
+* `Shared repositories <branching_a_project.html#a-reminder-about-shared-repositories>`_
+ - working tree and branch are colocated, but the repository is in a higher level
+ directory.
+
+* `Stacked branches <stacked.html>`_ - branch stores just its
+ unique revisions, using its parent's repository for common revisions.
+
+* `Lightweight checkouts <using_checkouts.html#getting-a-lightweight-checkout>`_
+ - branch is stored in a different location to the working tree.
+
+The best way to use Bazaar, however, depends on your needs. Let's take a
+look at some common workflows next.
diff --git a/doc/en/user-guide/distributed_intro.txt b/doc/en/user-guide/distributed_intro.txt
new file mode 100644
index 0000000..cd1f0bf
--- /dev/null
+++ b/doc/en/user-guide/distributed_intro.txt
@@ -0,0 +1,23 @@
+Distributed development
+=======================
+
+Motivation
+----------
+
+Distributed VCS tools offer new ways of working together,
+ways that better reflect the modern world we live in and
+ways that enable higher quality outcomes.
+
+The decentralized with shared mainline workflow
+-----------------------------------------------
+
+In this workflow, each developer has their own branch or branches, plus
+a checkout of the main branch. They do their work in their personal
+branch, then merge it into the mainline when it is ready.
+
+.. image:: images/workflows_shared.png
+
+Other distributed workflows are explored later in this chapter.
+
+..
+ vim: tw=74 ft=rst
diff --git a/doc/en/user-guide/entering_commands.txt b/doc/en/user-guide/entering_commands.txt
new file mode 100644
index 0000000..6e07b23
--- /dev/null
+++ b/doc/en/user-guide/entering_commands.txt
@@ -0,0 +1,41 @@
+Entering commands
+=================
+
+User interfaces
+---------------
+
+There are numerous user interfaces available for Bazaar.
+The core package provides a command line tool called **bzr** and
+graphical user interfaces (GUIs) are available as plug-ins.
+
+Using bzr
+---------
+
+The syntax is::
+
+ bzr [global-options] command [options and arguments]
+
+Global options affect how Bazaar operates and can appear either
+before or after ``command``. Command specific options must appear
+after the command but may be given either before, during or after any
+command-specific arguments.
+
+Common options
+--------------
+
+Some options are legal for all commands as shown below.
+
+ ========== ========= =================
+ Short form Long form Description
+ ========== ========= =================
+ -h --help get help
+ -v --verbose be more verbose
+ -q --quiet be more quiet
+ ========== ========= =================
+
+Quiet mode implies that only errors and warnings are displayed.
+This can be useful in scripts.
+
+Note: Most commands typically only support one level of verbosity though
+that may change in the future. To ask for a higher level of verbosity,
+simply specify the -v option multiple times.
diff --git a/doc/en/user-guide/filtered_views.txt b/doc/en/user-guide/filtered_views.txt
new file mode 100644
index 0000000..1a8db6a
--- /dev/null
+++ b/doc/en/user-guide/filtered_views.txt
@@ -0,0 +1,167 @@
+Filtered views
+==============
+
+Introducing filtered views
+--------------------------
+
+Views provide a mask over the tree so that users can focus on a subset
+of a tree when doing their work. There are several cases where this
+masking can be helpful. For example, technical writers and testers on
+many large projects may prefer to deal with just the directories/files
+in the project of interest to them.
+
+Developers may also wish to break a large set of changes into multiple
+commits by using views. While ``shelve`` and ``unshelve`` let developers
+put some changes aside for a later commit, views let developers specify
+what to include in (instead of exclude from) the next commit.
+
+After creating a view, commands that support a list of files - status,
+diff, commit, etc - effectively have that list of files implicitly
+given each time. An explicit list of files can still be given to these
+commands but the nominated files must be within the current view. In
+contrast, tree-centric commands - pull, merge, update, etc. - continue
+to operate on the whole tree but only report changes relevant to the
+current view. In both cases, Bazaar notifies the user each time it uses
+a view implicitly so that it is clear that the operation or output is
+being masked accordingly.
+
+Note: Filtered views are only supported in format 2a, the default in
+Bazaar 2.0, or later.
+
+
+Creating a view
+---------------
+
+This is done by specifying the files and directories using the ``view``
+command like this::
+
+ bzr view file1 file2 dir1 ...
+
+The output is::
+
+ Using 'my' view: file1, file2, dir1
+
+
+Listing the current view
+------------------------
+
+To see the current view, use the ``view`` command without arguments::
+
+ bzr view
+
+If no view is current, a message will be output saying ``No current view.``.
+Otherwise the name and content of the current view will be displayed
+like this::
+
+ 'my' view is: a, b, c
+
+
+Switching between views
+-----------------------
+
+In most cases, a view has a short life-span: it is created to make a
+selected change and is deleted once that change is committed. At other
+times, you may wish to create one or more named views and switch
+between them.
+
+To define a named view and switch to it::
+
+ bzr view --name view-name file1 dir1 ...
+
+For example::
+
+ bzr view --name doc NEWS doc/
+ Using doc view: NEWS, doc/
+
+To list a named view::
+
+ bzr view --name view-name
+
+To switch to a named view::
+
+ bzr view --switch view-name
+
+To list all views defined::
+
+ bzr view --all
+
+
+Temporarily disabling a view
+----------------------------
+
+To disable the current view without deleting it, you can switch to the
+pseudo view called ``off``. This can be useful when you need to see the
+whole tree for an operation or two (e.g. merge) but want to switch back
+to your view after that.
+
+To disable the current view without deleting it::
+
+ bzr view --switch off
+
+After doing the operations you need to, you can switch back to the
+view you were using by name. For example, if the previous view used
+the default name::
+
+ bzr view --switch my
+
+
+Deleting views
+--------------
+
+To delete the current view::
+
+ bzr view --delete
+
+To delete a named view::
+
+ bzr view --name view-name --delete
+
+To delete all views::
+
+ bzr view --delete --all
+
+
+Things to be aware of
+---------------------
+
+Defining a view does not delete the other files in the working
+tree - it merely provides a "lens" over the working tree.
+
+Views are stored as working tree metadata. They are not
+propagated by branch commands like pull, push and update.
+
+Views are defined in terms of file paths. If you move a
+file in a view to a location outside of the view, the view
+will no longer track that path. For example, if a view is
+defined as ``doc/`` and ``doc/NEWS`` gets moved to ``NEWS``,
+the views stays defined as ``doc/`` and does not get changed
+to ``doc/ NEWS``. Likewise, deleting a file in a view does
+not remove the file from that view.
+
+The commands that use the current view are:
+
+* status
+* diff
+* commit
+* add
+* remove
+* revert
+* mv
+* ls.
+
+Commands that operate on the full tree but only report changes
+inside the current view are:
+
+* pull
+* update
+* merge.
+
+Many commands currently ignore the current view. Over time,
+some of these commands may be added to the lists above as
+the need arises. By design, some commands will most likely
+always ignore the current view because showing the whole
+picture is the better thing to do. Commands in this group
+include:
+
+* log
+* info.
diff --git a/doc/en/user-guide/getting_help.txt b/doc/en/user-guide/getting_help.txt
new file mode 100644
index 0000000..a93ef4e
--- /dev/null
+++ b/doc/en/user-guide/getting_help.txt
@@ -0,0 +1,21 @@
+Getting help
+============
+
+Bazaar comes with a built-in on-line help system, accessed through::
+
+ bzr help
+
+You can ask for help on a command, or on non-command topics. To see a
+list of available help of each kind, use either::
+
+ bzr help commands
+ bzr help topics
+
+For help on a particular command, use either of these forms::
+
+ bzr help status
+ bzr status --help
+
+If you wish to search the help or read it as a larger document, the
+information is also available in the Bazaar User Reference.
+
diff --git a/doc/en/user-guide/gpg_signatures.txt b/doc/en/user-guide/gpg_signatures.txt
new file mode 100644
index 0000000..9fa53e9
--- /dev/null
+++ b/doc/en/user-guide/gpg_signatures.txt
@@ -0,0 +1,91 @@
+GnuPG Signatures
+=============================
+
+Reasons to Sign Your Repository
+--------------------------------
+
+Bazaar can sign revisions using GnuPG, a Free Software implementation of the
+OpenPGP digital signature format. By signing commits a person wanting to
+make use of a branch can be confident where the code came from, assuming the
+GnuPG keys used can be verified. This could for example prevent worry about
+compromised code in the case where a server hosting Bazaar branches has been
+hacked into. It could also be used to verify that all code is written by a
+select group of people, such as if contributor agreements are needed.
+
+Signatures are passed around with commits during branch, push, merge and other
+operations.
+
+Setting up GnuPG
+----------------
+
+There are many guides to creating a digital signature key with GnuPG. See
+for example the `GnuPG Handbook
+<http://www.gnupg.org/gph/en/manual.html#AEN26>`_ or the `Launchpad Wiki
+<https://help.launchpad.net/YourAccount/ImportingYourPGPKey>`_.
+
+
+Signing Commits
+---------------
+
+To sign commits as they are made turn on the ``create_signatures``
+configuration option in your ``bazaar.conf`` or ``locations.conf`` file::
+
+ create_signatures = always
+
+When you next make a commit it will ask for the pass phrase for your GnuPG key.
+If you want GnuPG to remember your password ensure you have ``gnupg-agent``
+installed.
+
+To sign previous commits to a branch use ``sign-my-commits``. This will go
+through all revisions in the branch and sign any which match your
+commit name. You can also pass the name of a contributor to ``sign-my-commits``
+to sign someone else's commits or if your GnuPG key does not match your Bazaar
+name and e-mail::
+
+ bzr sign-my-commits . "Amy Pond <amy@example.com>"
+
+It will not sign commits which already have a signature.
+
+To sign a single commit or a range of commits use the (hidden) command
+``re-sign``::
+
+ bzr re-sign -r 24
+
+``re-sign`` is also useful to change an existing signature.
+
+By default Bazaar will tell GnuPG to use a key with the same user
+identity as the one set with ``whoami``. To override this set
+``gpg_signing_key`` in bazaar.conf or locations.conf.
+
+ ``gpg_signing_key=DD4D5088``
+
+ ``gpg_signing_key=amy@example.com``
+
+Verifying Commits
+-----------------
+
+Signatures can be verified with the ``bzr verify-signatures`` command. By
+default this will check all commits in the branch and notify that all commits
+are signed by known trusted signatures. If not all commits have trusted
+signatures it will give a summary of the number of commits which are invalid,
+having missing keys or are not signed.
+
+The ``verify-signatures`` command can be given a comma separated list of key
+patters to specify a list of acceptable keys. It can also take a range of
+commits to verify in the current branch. Finally using the verbose option will
+list each key that is valid or authors for commits which failed::
+
+ $bzr verify-signatures -kamy -v -r 1..5
+ 1 commit with valid signature
+ Amy Pond <amy@example.com> signed 4 commits
+ 0 commits with unknown keys
+ 1 commit not valid
+ 1 commit by author The Doctor <doctor@example.com>
+ 0 commits not signed
+
+Work in Progress
+----------------
+
+There is still a number of digital signature related features which
+are hoped to be added to Bazaar soon. These include bzr explorer
+integration and setting branches to require signatures.
diff --git a/doc/en/user-guide/hooks.txt b/doc/en/user-guide/hooks.txt
new file mode 100644
index 0000000..6d1328d
--- /dev/null
+++ b/doc/en/user-guide/hooks.txt
@@ -0,0 +1,115 @@
+Using hooks
+===========
+
+What is a hook?
+---------------
+
+One way to customize Bazaar's behaviour is with *hooks*. Hooks allow you to
+perform actions before or after certain Bazaar operations. The operations
+include ``commit``, ``push``, ``pull``, and ``uncommit``.
+For a complete list of hooks and their parameters, see `Hooks
+<../user-reference/index.html#hooks>`_ in the User Reference.
+
+Most hooks are run on the client, but a few are run on the server. (Also
+see the `push-and-update plugin`_ that handles one special case of
+server-side operations.)
+
+.. _push-and-update plugin: http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
+
+Using hooks
+-----------
+
+To use a hook, you should `write a plugin`_. Instead of
+creating a new command, this plugin will define and install the hook. Here's
+an example::
+
+ from bzrlib import branch
+
+
+ def post_push_hook(push_result):
+ print "The new revno is %d" % push_result.new_revno
+
+
+ branch.Branch.hooks.install_named_hook('post_push', post_push_hook,
+ 'My post_push hook')
+
+.. _write a plugin: http://doc.bazaar.canonical.com/plugins/en/plugin-development.html
+
+To use this example, create a file named ``push_hook.py``, and stick it in
+``plugins`` subdirectory of your configuration directory. (If you have never
+installed any plugins, you may need to create the ``plugins`` directory).
+
+That's it! The next time you push, it should show "The new revno is...".
+Of course, hooks can be much more elaborate than this, because you have the
+full power of Python at your disposal. Now that you know how to use hooks,
+what you do with them is up to you.
+
+The plugin code does two things. First, it defines a function that will be
+run after ``push`` completes. (It could instead use an instance method or
+a callable object.) All push hooks take a single argument, the
+``push_result``.
+
+Second, the plugin installs the hook. The first argument ``'post_push'``
+identifies where to install the hook. The second argument is the hook
+itself. The third argument is a name ``'My post_push hook'``, which can be
+used in progress messages and error messages.
+
+To reduce the start-up time of Bazaar it is also possible to "lazily" install hooks,
+using the ``bzrlib.hooks.install_lazy_named_hook`` function. This removes the need
+to load the module that contains the hook point just to install the hook. Here's lazy
+version of the example above::
+
+ from bzrlib import hooks
+
+ def post_push_hook(push_result):
+ print "The new revno is %d" % push_result.new_revno
+
+
+ hooks.install_lazy_named_hook('bzrlib.branch', 'Branch.hooks',
+ 'post_push', post_push_hook, 'My post_push hook')
+
+Debugging hooks
+---------------
+
+To get a list of installed hooks (and available hook points), use the hidden
+``hooks`` command::
+
+ bzr hooks
+
+
+Example: a merge plugin
+-----------------------
+
+Here's a complete plugin that demonstrates the ``Merger.merge_file_content``
+hook. It installs a hook that forces any merge of a file named ``*.xml``
+to be a conflict, even if Bazaar thinks it can merge it cleanly.
+
+``merge_xml.py``::
+
+ """Custom 'merge' logic for *.xml files.
+
+ Always conflicts if both branches have changed the file.
+ """
+
+ from bzrlib.merge import PerFileMerger, Merger
+
+ def merge_xml_files_hook(merger):
+ """Hook to merge *.xml files"""
+ return AlwaysConflictXMLMerger(merger)
+
+ class AlwaysConflictXMLMerger(PerFileMerger):
+
+ def file_matches(self, params):
+ filename = self.get_filename(params, self.merger.this_tree)
+ return filename.endswith('.xml')
+
+ def merge_matching(self, params):
+ return 'conflicted', params.this_lines
+
+ Merger.hooks.install_named_hook(
+ 'merge_file_content', merge_xml_files_hook, '*.xml file merge')
+
+``merge_file_content`` hooks are executed for each file to be merged. For
+a more a complex example look at the ``news_merge`` plugin that's bundled with
+Bazaar in the ``bzrlib/plugins`` directory.
+
diff --git a/doc/en/user-guide/http_smart_server.txt b/doc/en/user-guide/http_smart_server.txt
new file mode 100644
index 0000000..05f7a6a
--- /dev/null
+++ b/doc/en/user-guide/http_smart_server.txt
@@ -0,0 +1,298 @@
+Serving Bazaar with Apache
+==========================
+
+This document describes one way to set up a Bazaar HTTP smart server,
+using Apache 2.0 and FastCGI or mod_python or mod_wsgi.
+
+For more information on the smart server, and other ways to configure it
+see the main `smart server documentation <server.html>`_.
+
+Example
+-------
+
+You have a webserver already publishing `/srv/example.com/www/code` as
+`http://example.com/code/...` with plain HTTP. It contains bzr branches and
+directories like `/srv/example.com/www/code/branch-one` and
+`/srv/example.com/www/code/my-repo/branch-two`. You want to provide read-only
+smart server access to these directories in addition to the existing HTTP
+access.
+
+Configuring Apache 2.0
+----------------------
+
+FastCGI
+~~~~~~~
+
+First, configure mod_fastcgi, e.g. by adding lines like these to your
+httpd.conf::
+
+ LoadModule fastcgi_module /usr/lib/apache2/modules/mod_fastcgi.so
+ FastCgiIpcDir /var/lib/apache2/fastcgi
+
+In our example, we're already serving `/srv/example.com/www/code` at
+`http://example.com/code`, so our existing Apache configuration would look
+like::
+
+ Alias /code /srv/example.com/www/code
+ <Directory /srv/example.com/www/code>
+ Options Indexes
+ # ...
+ </Directory>
+
+We need to change it to handle all requests for URLs ending in `.bzr/smart`. It
+will look like::
+
+ Alias /code /srv/example.com/www/code
+ <Directory /srv/example.com/www/code>
+ Options Indexes FollowSymLinks
+ RewriteEngine On
+ RewriteBase /code
+ RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
+ </Directory>
+
+ # bzr-smart.fcgi isn't under the DocumentRoot, so Alias it into the URL
+ # namespace so it can be executed.
+ Alias /srv/example.com/scripts/bzr-smart.fcgi /srv/example.com/scripts/bzr-smart.fcgi
+ <Directory /srv/example.com/scripts>
+ Options ExecCGI
+ <Files bzr-smart.fcgi>
+ SetHandler fastcgi-script
+ </Files>
+ </Directory>
+
+This instructs Apache to hand requests for any URL ending with `/.bzr/smart`
+inside `/code` to a Bazaar smart server via FastCGI.
+
+Refer to the mod_rewrite_ and mod_fastcgi_ documentation for further
+information.
+
+.. _mod_rewrite: http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
+.. _mod_fastcgi: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
+
+mod_python
+~~~~~~~~~~
+
+First, configure mod_python, e.g. by adding lines like these to your
+httpd.conf::
+
+ LoadModule python_module /usr/lib/apache2/modules/mod_python.so
+
+Define the rewrite rules with mod_rewrite the same way as for FastCGI, except
+change::
+
+ RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
+
+to::
+
+ RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.py
+
+Like with mod_fastcgi, we also define how our script is to be handled::
+
+ Alias /srv/example.com/scripts/bzr-smart.py /srv/example.com/scripts/bzr-smart.py
+ <Directory /srv/example.com/scripts>
+ <Files bzr-smart.py>
+ PythonPath "sys.path+['/srv/example.com/scripts']"
+ AddHandler python-program .py
+ PythonHandler bzr-smart::handler
+ </Files>
+ </Directory>
+
+This instructs Apache to hand requests for any URL ending with `/.bzr/smart`
+inside `/code` to a Bazaar smart server via mod_python.
+
+NOTE: If you don't have bzrlib in your PATH, you will be need to change the
+following line::
+
+ PythonPath "sys.path+['/srv/example.com/scripts']"
+
+To::
+
+ PythonPath "['/path/to/bzr']+sys.path+['/srv/example.com/scripts']"
+
+
+Refer to the mod_python_ documentation for further information.
+
+.. _mod_python: http://www.modpython.org/
+
+
+mod_wsgi
+~~~~~~~~
+
+First, configure mod_wsgi, e.g. enabling the mod with a2enmod wsgi.
+We need to change it to handle all requests for URLs ending in `.bzr/smart`. It
+will look like::
+
+ WSGIScriptAliasMatch ^/code/.*/\.bzr/smart$ /srv/example.com/scripts/bzr.wsgi
+
+ #The three next lines allow regular GETs to work too
+ RewriteEngine On
+ RewriteCond %{REQUEST_URI} !^/code/.*/\.bzr/smart$
+ RewriteRule ^/code/(.*/\.bzr/.*)$ /srv/example.com/www/code/$1 [L]
+
+ <Directory /srv/example.com/www/code>
+ WSGIApplicationGroup %{GLOBAL}
+ </Directory>
+
+This instructs Apache to hand requests for any URL ending with `/.bzr/smart`
+inside `/code` to a Bazaar smart server via WSGI, and any other URL inside
+`/code` to be served directly by Apache.
+
+Refer to the mod_wsgi_ documentation for further information.
+
+.. _mod_wsgi: http://code.google.com/p/modwsgi/
+
+Configuring Bazaar
+------------------
+
+FastCGI
+~~~~~~~
+
+We've configured Apache to run the smart server at
+`/srv/example.com/scripts/bzr-smart.fcgi`. This is just a simple script we need
+to write to configure a smart server, and glue it to the FastCGI gateway.
+Here's what it looks like::
+
+ import fcgi
+ from bzrlib.transport.http import wsgi
+
+ smart_server_app = wsgi.make_app(
+ root='/srv/example.com/www/code',
+ prefix='/code/',
+ path_var='REQUEST_URI',
+ readonly=True,
+ load_plugins=True,
+ enable_logging=True)
+
+ fcgi.WSGIServer(smart_server_app).run()
+
+The `fcgi` module can be found at http://svn.saddi.com/py-lib/trunk/fcgi.py. It
+is part of flup_.
+
+.. _flup: http://www.saddi.com/software/flup/
+
+mod_python
+~~~~~~~~~~
+
+We've configured Apache to run the smart server at
+`/srv/example.com/scripts/bzr-smart.py`. This is just a simple script we need
+to write to configure a smart server, and glue it to the mod_python gateway.
+Here's what it looks like::
+
+ import modpywsgi
+ from bzrlib.transport.http import wsgi
+
+ smart_server_app = wsgi.make_app(
+ root='/srv/example.com/www/code',
+ prefix='/code/',
+ path_var='REQUEST_URI',
+ readonly=True,
+ load_plugins=True,
+ enable_logging=True)
+
+ def handler(request):
+ """Handle a single request."""
+ wsgi_server = modpywsgi.WSGIServer(smart_server_app)
+ return wsgi_server.run(request)
+
+The `modpywsgi` module can be found at
+http://ice.usq.edu.au/svn/ice/trunk/apps/ice-server/modpywsgi.py. It was
+part of pocoo_. You sould make sure you place modpywsgi.py in the same
+directory as bzr-smart.py (ie. /srv/example.com/scripts/).
+
+.. _pocoo: http://dev.pocoo.org/projects/pocoo/
+
+
+mod_wsgi
+~~~~~~~~
+
+We've configured Apache to run the smart server at
+`/srv/example.com/scripts/bzr.wsgi`. This is just a simple script we need
+to write to configure a smart server, and glue it to the WSGI gateway.
+Here's what it looks like::
+
+ from bzrlib.transport.http import wsgi
+
+ def application(environ, start_response):
+ app = wsgi.make_app(
+ root="/srv/example.com/www/code/",
+ prefix="/code",
+ readonly=True,
+ enable_logging=False)
+ return app(environ, start_response)
+
+Clients
+-------
+
+Now you can use `bzr+http://` URLs or just `http://` URLs, e.g.::
+
+ bzr log bzr+http://example.com/code/my-branch
+
+Plain HTTP access should continue to work::
+
+ bzr log http://example.com/code/my-branch
+
+Advanced configuration
+----------------------
+
+Because the Bazaar HTTP smart server is a WSGI application, it can be used with
+any 3rd-party WSGI middleware or server that conforms the WSGI standard. The
+only requirements are:
+
+ * to construct a `SmartWSGIApp`, you need to specify a **root transport** that it
+ will serve.
+ * each request's `environ` dict must have a **'bzrlib.relpath'** variable set.
+
+The `make_app` helper used in the example constructs a `SmartWSGIApp` with a
+transport based on the `root` path given to it, and calculates the
+'bzrlib.relpath` for each request based on the `prefix` and `path_var`
+arguments. In the example above, it will take the 'REQUEST_URI' (which is set
+by Apache), strip the '/code/' prefix and the '/.bzr/smart' suffix, and set that
+as the 'bzrlib.relpath', so that a request for '/code/foo/bar/.bzr/smart' will
+result in a 'bzrlib.relpath' of 'foo/bzr'.
+
+It's possible to configure a smart server for a non-local transport, or that
+does arbitrary path translations, etc, by constructing a `SmartWSGIApp`
+directly. Refer to the docstrings of `bzrlib.transport.http.wsgi` and the `WSGI
+standard`_ for further information.
+
+.. _WSGI standard: http://www.python.org/dev/peps/pep-0333/
+
+
+Pushing over the HTTP smart server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It is possible to allow pushing data over the HTTP smart server. The
+easiest way to do this, is to just supply ``readonly=False`` to the
+``wsgi.make_app()`` call. But be careful, because the smart protocol does
+not contain any Authentication. So if you enable write support, you will
+want to restrict access to ``.bzr/smart`` URLs to restrict who can
+actually write data on your system, e.g. in apache it looks like::
+
+ <Location /code>
+ AuthType Basic
+ AuthName "example"
+ AuthUserFile /srv/example.com/conf/auth.passwd
+ <LimitExcept GET>
+ Require valid-user
+ </LimitExcept>
+ </Location>
+
+At this time, it is not possible to allow some people to have read-only
+access and others to have read-write access to the same URLs. Because at
+the HTTP layer (which is doing the Authenticating), everything is just a
+POST request. However, it would certainly be possible to have HTTPS
+require authentication and use a writable server, and plain HTTP allow
+read-only access.
+
+If bzr gives an error like this when accessing your HTTPS site::
+
+ bzr: ERROR: Connection error: curl connection error (server certificate verification failed.
+ CAfile:/etc/ssl/certs/ca-certificates.crt CRLfile: none)
+
+You can workaround it by using ``https+urllib`` rather than ``http`` in your
+URL, or by uninstalling pycurl. See `bug 82086`_ for more details.
+
+.. _bug 82086: https://bugs.launchpad.net/bzr/+bug/82086
+
+..
+ vim: ft=rst tw=74 et
diff --git a/doc/en/user-guide/images/workflows_centralized.png b/doc/en/user-guide/images/workflows_centralized.png
new file mode 100644
index 0000000..352ea59
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_centralized.png
Binary files differ
diff --git a/doc/en/user-guide/images/workflows_centralized.svg b/doc/en/user-guide/images/workflows_centralized.svg
new file mode 100644
index 0000000..4a09de0
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_centralized.svg
@@ -0,0 +1,1542 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_centralized.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_centralized.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.4142136"
+ inkscape:cx="536.99132"
+ inkscape:cy="369.73871"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1024"
+ inkscape:window-height="712"
+ inkscape:window-x="-4"
+ inkscape:window-y="-4" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr checkout</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(492.85715,-2.8571472)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.71429"
+ y="191.52307"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="777.71429"
+ y="191.52307">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="819.5625"
+ y="191.21948"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="819.5625"
+ y="191.21948">bzr update</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.29065037;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 539.95542,466.93556 L 415.85387,476.71718 L 426.49116,461.93102 L 358.1094,466.70812 C 358.1094,466.70812 347.47211,481.94916 346.96566,481.94916 C 346.45858,481.94916 322.14533,462.15846 322.14533,462.15846 C 322.14533,462.15846 379.38334,441.45772 379.88978,441.45772 C 379.38334,441.00284 369.25249,456.01673 369.25249,456.24417 L 448.27282,451.23935 L 437.63489,466.48068 L 551.09912,456.92649 L 539.95542,466.93556 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(51.511043,348.5966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="334.36819"
+ y="540.97681"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="334.36819"
+ y="540.97681">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="369.5625"
+ y="544.09448"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="369.5625"
+ y="544.09448">bzr commit</tspan></text>
+ </g>
+</svg>
diff --git a/doc/en/user-guide/images/workflows_gatekeeper.png b/doc/en/user-guide/images/workflows_gatekeeper.png
new file mode 100644
index 0000000..45ef8f0
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_gatekeeper.png
Binary files differ
diff --git a/doc/en/user-guide/images/workflows_gatekeeper.svg b/doc/en/user-guide/images/workflows_gatekeeper.svg
new file mode 100644
index 0000000..6490454
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_gatekeeper.svg
@@ -0,0 +1,2137 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_gatekeeper.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_manualpqm.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient7932"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7934"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7936"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7938"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7940"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7942"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7944"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient7946"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7948"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7950"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient7952"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7954"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7956"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7958"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7960"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7962"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient7964"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7966"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient7968"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7990"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <radialGradient
+ xlink:href="#linearGradient1861"
+ r="26.285225"
+ inkscape:collect="always"
+ id="radialGradient1887"
+ fy="44.906904"
+ fx="34.609807"
+ cy="45.317611"
+ cx="33.865884"
+ gradientTransform="scale(1.3025634,0.767717)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1861"
+ r="27.313507"
+ inkscape:collect="always"
+ id="radialGradient1885"
+ fy="96.522109"
+ fx="44.745902"
+ cy="96.948882"
+ cx="45.838441"
+ gradientTransform="scale(1.0963096,0.9121511)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="69.990188"
+ y1="60.176033"
+ xlink:href="#linearGradient1864"
+ x2="54.084046"
+ x1="51.210938"
+ inkscape:collect="always"
+ id="linearGradient1883"
+ gradientTransform="scale(1.2343409,0.8101489)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1858">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop1859" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop1860" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1861">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop1862" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1863" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1864">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop1865" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1866" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1867">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop1868" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1869" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11180">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop11182" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11184" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11174">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop11176" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11178" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11168">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop11170" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11172" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11162">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop11164" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop11166" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="559.94128"
+ inkscape:cy="472.46874"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1416"
+ inkscape:window-height="825"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,39.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,227.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(635.63525,491.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="73.4375"
+ y="510.12573"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="73.4375"
+ y="510.12573">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(466.18527,201.5491)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="751.04242"
+ y="395.37573"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="751.04242"
+ y="395.37573">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="778.89062"
+ y="392.32886"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="778.89062"
+ y="392.32886"
+ id="tspan2963">make changes</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.52894235;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 578.13978,492.35651 L 518.11306,536.64644 L 515.93459,528.2361 L 482.53728,552.4378 C 482.53728,552.4378 484.9546,560.99862 484.68867,561.16617 C 484.42242,561.33391 461.26447,562.83001 461.26447,562.83001 C 461.26447,562.83001 480.44933,537.04707 480.71524,536.87954 C 480.21048,536.89659 482.77445,545.21473 482.89387,545.28997 L 521.75768,517.49359 L 524.17482,526.05472 L 578.73553,485.35896 L 578.13978,492.35651 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(449.56027,418.37723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="732.41742"
+ y="611.97729"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="732.41742"
+ y="611.97729">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="768.26562"
+ y="608.23511"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="768.26562"
+ y="608.23511">request merge</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="75.5625"
+ y="228.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="75.5625"
+ y="228.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="556.98438"
+ y="165.64139"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="556.98438"
+ y="165.64139">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-477.33182,37.826027)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.0657387,0,0,1.0382501,-36.482679,-19.544354)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.27460909;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path7875"
+ d="M 313.49127,554.98551 L 266.8349,508.88833 L 275.69462,507.21539 L 250.19978,481.56811 C 250.19978,481.56811 241.18156,483.42447 241.00507,483.22026 C 240.82835,483.0158 239.25232,465.23179 239.25232,465.23179 C 239.25232,465.23179 266.41286,479.96469 266.58935,480.16889 C 266.57138,479.78127 257.8088,481.75026 257.72954,481.84196 L 287.01109,511.6872 L 277.99254,513.54344 L 320.8627,555.44302 L 313.49127,554.98551 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <g
+ id="g7884"
+ transform="translate(322.22009,479.97324)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient7932);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path7886"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient7934);fill-opacity:1"
+ id="g7888">
+ <path
+ style="fill:url(#linearGradient7936);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path7890"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient7938);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path7892"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient7940);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path7894"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient7942);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient7944);stroke-width:1.44734821pt"
+ id="rect7896"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient7946);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path7898"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient7948);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path7900"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient7950);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect7902"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient7952);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient7954);stroke-width:1.4649456pt"
+ id="rect7904"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient7956);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path7906"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g7908">
+ <path
+ style="fill:url(#linearGradient7958);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path7910"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient7960);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path7912"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient7962);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path7914"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient7964);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path7916"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient7966);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path7918"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient7968);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path7920"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient7990);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path7922"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text7924"><tspan
+ id="tspan7926">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text7928"><tspan
+ id="tspan7930">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g11201"
+ transform="translate(224.98935,560.87966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11204"
+ d="M 61.208646,74.540863 C 65.958047,79.724425 68.980394,89.011639 75.672733,89.01164 C 82.14919,87.211791 83.012718,71.805094 83.876245,68.493375 C 76.536261,73.532948 68.980395,76.412704 61.208646,74.540863 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,-0.8485902,18.11889)"
+ style="fill:#ebd5bb;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path11206"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#354b63;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path11208"
+ d="M 32.210275,101.34753 C 31.819634,126.54379 96.449036,129.42515 96.292736,101.34753 C 97.837516,79.018786 86.732289,66.323086 83.972618,68.481556 C 82.571377,69.577533 82.050742,93.917319 72.58281,88.318677 C 67.97993,85.596878 62.831472,75.141814 60.578865,74.794949 C 57.17979,74.271545 50.671042,71.519447 44.693328,66.368738 C 43.125035,65.017418 32.739724,78.907727 32.210275,101.34753 z " />
+ <path
+ style="fill:#7e5429;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccscc"
+ id="path14564"
+ d="M 67.304802,16.686453 C 54.985668,-4.2976037 31.742548,13.847204 34.832083,38.13111 C 28.606909,39.936495 13.38594,55.735942 54.610465,51.217079 C 72.973357,49.204214 127.11969,28.718598 84.679736,22.863615 C 78.797006,1.2972292 67.040662,6.1031815 67.304802,16.686453 z " />
+ <path
+ style="fill:url(#linearGradient1883);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1879"
+ d="M 89.582928,41.074792 C 78.886738,46.748497 62.561318,51.815798 53.926678,52.762292 C 47.018518,53.519536 42.160188,53.578455 38.114178,53.356042 C 39.550848,66.152312 50.849068,76.168541 64.707928,76.168542 C 79.538378,76.168542 91.582928,64.747093 91.582928,50.668542 C 91.582928,47.276803 90.850878,44.035951 89.582928,41.074792 z " />
+ <path
+ style="fill:url(#radialGradient1885);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1884"
+ d="M 43.031249,70.1875 C 35.995246,80.448202 32.902215,93.581638 34.156249,105.875 C 40.334493,118.62839 56.831543,120.43683 69.499999,119.875 C 80.494576,119.32475 94.949065,113.14258 93.695531,100.00002 C 93.939855,90.023763 92.261916,78.780004 84.874999,71.5 C 82.650684,78.396104 83.536195,89.443626 74.999999,91.84375 C 65.062996,91.017122 64.05284,76.914438 54.283675,75.750529 C 50.352102,75.051855 46.009593,69.547093 43.031249,70.1875 z " />
+ <path
+ style="fill:url(#radialGradient1887);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1886"
+ d="M 51.968749,10.15625 C 40.703741,13.843837 36.038494,27.433868 37.531249,38.375 C 35.900906,41.584912 25.71302,45.254989 31.843749,49.03125 C 53.068339,53.154256 75.12687,46.221276 93.715523,36.077723 C 100.42684,33.740896 99.810666,26.846559 92.384918,26.66513 C 86.324151,26.558371 81.674394,23.81643 81.165374,17.307044 C 79.826948,13.582045 74.107596,6.6890987 71.01108,12.623276 C 71.073069,19.511996 65.891703,20.102559 63.230392,14.042893 C 60.468574,10.851605 56.135557,9.1882781 51.968749,10.15625 z " />
+ </g>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2488"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(82.857147,474.9866)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="365.71429"
+ y="668.60229"
+ id="text2490"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2492"
+ x="365.71429"
+ y="668.60229">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="401.5625"
+ y="665.76636"
+ id="text2494"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2496"
+ x="401.5625"
+ y="665.76636">accept or reject</tspan></text>
+ </g>
+</svg>
diff --git a/doc/en/user-guide/images/workflows_localcommit.png b/doc/en/user-guide/images/workflows_localcommit.png
new file mode 100644
index 0000000..f98e57b
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_localcommit.png
Binary files differ
diff --git a/doc/en/user-guide/images/workflows_localcommit.svg b/doc/en/user-guide/images/workflows_localcommit.svg
new file mode 100644
index 0000000..2e7ad85
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_localcommit.svg
@@ -0,0 +1,1575 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_localcommit.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_localcommit.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient8493"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient8491"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient8485">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop8487" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop8489" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.70710678"
+ inkscape:cx="503.09779"
+ inkscape:cy="201.79714"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1024"
+ inkscape:window-height="712"
+ inkscape:window-x="-4"
+ inkscape:window-y="-4" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="763.75"
+ y="188.09448"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="763.75"
+ y="188.09448">bzr commit --local</tspan><tspan
+ sodipodi:role="line"
+ x="763.75"
+ y="228.09448"
+ id="tspan7922" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="801.4375"
+ y="609.46948"
+ id="text7881"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan7883"
+ x="801.4375"
+ y="609.46948">bzr unbind</tspan><tspan
+ sodipodi:role="line"
+ x="801.4375"
+ y="641.46948"
+ id="tspan8507">bzr commit</tspan><tspan
+ sodipodi:role="line"
+ x="801.4375"
+ y="673.46948"
+ id="tspan8511">bzr bind</tspan></text>
+ <g
+ id="g7903"
+ transform="translate(21.8125,50.285718)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path7897"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text7899"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan7901"
+ sodipodi:role="line">1</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="351.375"
+ y="272.69269"
+ id="text7908"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan7910"
+ x="351.375"
+ y="272.69269">bzr checkout</tspan></text>
+ <g
+ id="g7912"
+ transform="translate(438.71429,-31.85714)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path7914"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text7916"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan7918"
+ sodipodi:role="line">2</tspan></text>
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.58159733;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path8495"
+ d="M 530.64409,443.90791 L 411.93077,455.56731 L 422.10621,437.94266 L 356.69344,443.63682 C 356.69344,443.63682 346.51796,461.80368 346.0335,461.80368 C 345.54844,461.80368 322.2908,438.21377 322.2908,438.21377 C 322.2908,438.21377 377.0437,413.53911 377.52817,413.53911 C 377.0437,412.99691 367.35272,430.89301 367.35272,431.16411 L 442.94217,425.19852 L 432.76613,443.36572 L 541.30393,431.97742 L 530.64409,443.90791 z " />
+ <g
+ id="g8497"
+ transform="translate(446.57144,390.28572)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path8499"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text8501"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan8503"
+ sodipodi:role="line">2</tspan></text>
+ </g>
+ <g
+ id="g8513"
+ transform="translate(59.142865,311.71429)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path8515"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text8517"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan8519"
+ sodipodi:role="line">3</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="389.375"
+ y="534.40698"
+ id="text8525"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan8527"
+ x="389.375"
+ y="534.40698">bzr commit</tspan></text>
+ </g>
+</svg>
diff --git a/doc/en/user-guide/images/workflows_peer.png b/doc/en/user-guide/images/workflows_peer.png
new file mode 100644
index 0000000..1ec9e04
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_peer.png
Binary files differ
diff --git a/doc/en/user-guide/images/workflows_peer.svg b/doc/en/user-guide/images/workflows_peer.svg
new file mode 100644
index 0000000..f68a774
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_peer.svg
@@ -0,0 +1,1589 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_peer.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_peer.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="536.99132"
+ inkscape:cy="369.73871"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1759"
+ inkscape:window-height="875"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ id="g5256"
+ transform="translate(601.5744,309.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(541.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(111.5744,317.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,300.80614,215.0989)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 357.16674,263.66524 L 470.27399,251.12251 L 460.57906,270.08242 L 522.9028,263.95688 C 522.9028,263.95688 532.59773,244.41369 533.05931,244.41369 C 533.52148,244.41369 555.68079,269.79078 555.68079,269.79078 C 555.68079,269.79078 503.51355,296.33479 503.05197,296.33479 C 503.51355,296.91808 512.74689,277.66616 512.74689,277.37453 L 440.72705,283.79207 L 450.42255,264.24852 L 347.01023,276.4996 L 357.16674,263.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="635.5625"
+ y="201.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="635.5625"
+ y="201.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(318.85715,7.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="601.71429"
+ y="199.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="601.71429"
+ y="199.52307">2</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.49513507;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 426.28539,558.28183 L 482.38891,565.59894 L 477.58003,554.5382 L 508.49388,558.1117 C 508.49388,558.1117 513.30276,569.51271 513.53172,569.51271 C 513.76096,569.51271 524.75243,554.70834 524.75243,554.70834 C 524.75243,554.70834 498.87641,539.22321 498.64746,539.22321 C 498.87641,538.88294 503.45634,550.11403 503.45634,550.28417 L 467.73303,546.54033 L 472.54219,557.94156 L 421.24757,550.79458 L 426.28539,558.28183 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-194.48896,372.41254)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="87.591393"
+ y="566.02826"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="87.591393"
+ y="566.02826">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="119.03906"
+ y="543.19232"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="119.03906"
+ y="543.19232">merge changes</tspan><tspan
+ sodipodi:role="line"
+ x="119.03906"
+ y="583.19232"
+ id="tspan2716">from peer</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2670"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-187.14285,5.361605)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="94.539062"
+ y="198.97729"
+ id="text2672"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2674"
+ x="94.539062"
+ y="198.97729">1</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="129.5625"
+ y="195.43823"
+ id="text2676"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2678"
+ x="129.5625"
+ y="195.43823">start project</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2680"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-20.189728,217.62723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="261.83594"
+ y="411.22729"
+ id="text2682"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2684"
+ x="261.83594"
+ y="411.22729">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="294.51562"
+ y="388.40698"
+ id="text2686"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2688"
+ x="294.51562"
+ y="388.40698">record</tspan><tspan
+ sodipodi:role="line"
+ x="294.51562"
+ y="428.40698"
+ id="tspan2712">changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2690"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(321.8001,372.41254)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="603.88049"
+ y="566.02826"
+ id="text2692"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2694"
+ x="603.88049"
+ y="566.02826">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="635.32812"
+ y="543.19232"
+ id="text2696"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2698"
+ x="635.32812"
+ y="543.19232">merge changes</tspan><tspan
+ sodipodi:role="line"
+ x="635.32812"
+ y="583.19232"
+ id="tspan2718">from peer</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2700"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(462.85715,216.65848)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="744.88281"
+ y="410.25854"
+ id="text2702"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2704"
+ x="744.88281"
+ y="410.25854">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.5625"
+ y="387.43823"
+ id="text2706"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2708"
+ x="777.5625"
+ y="387.43823">record</tspan><tspan
+ sodipodi:role="line"
+ x="777.5625"
+ y="427.43823"
+ id="tspan2714">changes</tspan></text>
+ <path
+ inkscape:export-ydpi="41.964157"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ d="M 515.71461,505.61603 L 459.61109,512.93314 L 464.41997,501.8724 L 433.50612,505.4459 C 433.50612,505.4459 428.69724,516.84691 428.46828,516.84691 C 428.23904,516.84691 417.24757,502.04254 417.24757,502.04254 C 417.24757,502.04254 443.12359,486.55741 443.35254,486.55741 C 443.12359,486.21714 438.54366,497.44823 438.54366,497.61837 L 474.26697,493.87453 L 469.45781,505.27576 L 520.75243,498.12878 L 515.71461,505.61603 z "
+ id="path2710"
+ sodipodi:nodetypes="cccccccccccc"
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.49513507;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1" />
+ </g>
+</svg>
diff --git a/doc/en/user-guide/images/workflows_pqm.png b/doc/en/user-guide/images/workflows_pqm.png
new file mode 100644
index 0000000..a9ffc6a
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_pqm.png
Binary files differ
diff --git a/doc/en/user-guide/images/workflows_pqm.svg b/doc/en/user-guide/images/workflows_pqm.svg
new file mode 100644
index 0000000..8c6dcbf
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_pqm.svg
@@ -0,0 +1,1794 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_pqm.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_pqm.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7934"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ id="linearGradient1858">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop1859" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop1860" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1861">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop1862" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1863" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1864">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop1865" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1866" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1867">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop1868" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1869" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11180">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop11182" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11184" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11174">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop11176" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11178" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11168">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop11170" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11172" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11162">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop11164" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop11166" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="559.94128"
+ inkscape:cy="392.13154"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1416"
+ inkscape:window-height="825"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2791"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(562.85715,227.14285)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="844.88281"
+ y="420.74292"
+ id="text2793"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2795"
+ x="844.88281"
+ y="420.74292">3</tspan></text>
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,39.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,227.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(593.63525,509.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,417.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,874.16045,452.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="92.546875"
+ y="509.71948"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="92.546875"
+ y="509.71948">Server</tspan><tspan
+ sodipodi:role="line"
+ x="92.546875"
+ y="569.71948"
+ id="tspan2803">(PQM)</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(558.85715,89.5491)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="841.25"
+ y="283.37573"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="841.25"
+ y="283.37573">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="874.89062"
+ y="264.32886"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="874.89062"
+ y="264.32886"
+ id="tspan2788">make</tspan><tspan
+ sodipodi:role="line"
+ x="874.89062"
+ y="304.32886"
+ id="tspan2815">changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(449.56027,432.37723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="732.41742"
+ y="625.97729"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="732.41742"
+ y="625.97729">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="768.26562"
+ y="622.23511"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="768.26562"
+ y="622.23511">accept or reject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="75.5625"
+ y="228.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="75.5625"
+ y="228.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="556.98438"
+ y="165.64139"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="556.98438"
+ y="165.64139">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-477.33182,37.826027)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.0657387,0,0,1.0382501,-36.482679,-19.544354)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <g
+ id="g11201"
+ transform="translate(224.98935,560.87966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2488"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(44.857147,386.9866)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="327.71429"
+ y="580.60229"
+ id="text2490"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2492"
+ x="327.71429"
+ y="580.60229">5</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="363.5625"
+ y="577.76636"
+ id="text2494"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2496"
+ x="363.5625"
+ y="577.76636">request merge</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path2801"
+ d="M 530.83326,472.52373 L 417.72601,485.06646 L 427.42094,466.10655 L 365.0972,472.23209 C 365.0972,472.23209 355.40227,491.77528 354.94069,491.77528 C 354.47852,491.77528 332.31921,466.39819 332.31921,466.39819 C 332.31921,466.39819 384.48645,439.85418 384.94803,439.85418 C 384.48645,439.27089 375.25311,458.52281 375.25311,458.81444 L 447.27295,452.3969 L 437.57745,471.94045 L 540.98977,459.68937 L 530.83326,472.52373 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="878.89062"
+ y="396.40698"
+ id="text2811"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="878.89062"
+ y="396.40698"
+ id="tspan2813">request</tspan><tspan
+ sodipodi:role="line"
+ x="878.89062"
+ y="436.40698"
+ id="tspan2817">review</tspan></text>
+ </g>
+</svg>
diff --git a/doc/en/user-guide/images/workflows_shared.png b/doc/en/user-guide/images/workflows_shared.png
new file mode 100644
index 0000000..47ce0cb
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_shared.png
Binary files differ
diff --git a/doc/en/user-guide/images/workflows_shared.svg b/doc/en/user-guide/images/workflows_shared.svg
new file mode 100644
index 0000000..762155e
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_shared.svg
@@ -0,0 +1,1594 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_shared.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_shared.png"
+ inkscape:export-xdpi="49.419998"
+ inkscape:export-ydpi="49.419998">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.8"
+ inkscape:cx="578.40513"
+ inkscape:cy="404.22798"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1405"
+ inkscape:window-height="869"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(492.85715,-2.8571472)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.71429"
+ y="191.52307"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="777.71429"
+ y="191.52307">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="819.5625"
+ y="179.59448"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="819.5625"
+ y="179.59448">bzr pull</tspan><tspan
+ sodipodi:role="line"
+ x="819.5625"
+ y="219.59448"
+ id="tspan2963">bzr merge</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.29065037;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 539.95542,466.93556 L 415.85387,476.71718 L 426.49116,461.93102 L 358.1094,466.70812 C 358.1094,466.70812 347.47211,481.94916 346.96566,481.94916 C 346.45858,481.94916 322.14533,462.15846 322.14533,462.15846 C 322.14533,462.15846 379.38334,441.45772 379.88978,441.45772 C 379.38334,441.00284 369.25249,456.01673 369.25249,456.24417 L 448.27282,451.23935 L 437.63489,466.48068 L 551.09912,456.92649 L 539.95542,466.93556 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(51.511043,348.5966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="334.36819"
+ y="540.97681"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="334.36819"
+ y="540.97681">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="369.5625"
+ y="544.09448"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="369.5625"
+ y="544.09448">bzr commit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="61.5625"
+ y="240.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="61.5625"
+ y="240.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="563.43756"
+ y="582.09442"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="563.43756"
+ y="582.09442">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006169;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-501.33182,49.826027)" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.1405493,0,0,1.0364644,-57.067817,396.76108)" />
+ </g>
+</svg>
diff --git a/doc/en/user-guide/images/workflows_single.png b/doc/en/user-guide/images/workflows_single.png
new file mode 100644
index 0000000..03da3ef
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_single.png
Binary files differ
diff --git a/doc/en/user-guide/images/workflows_single.svg b/doc/en/user-guide/images/workflows_single.svg
new file mode 100644
index 0000000..1d312a2
--- /dev/null
+++ b/doc/en/user-guide/images/workflows_single.svg
@@ -0,0 +1,1079 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_single.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.4142136"
+ inkscape:cx="536.99132"
+ inkscape:cy="529.01021"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1465"
+ inkscape:window-height="896"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ id="g5256"
+ transform="translate(631.5744,227.66157)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="345.5625"
+ y="218.05542"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ x="345.5625"
+ y="218.05542"
+ id="tspan2399">create project</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,24.174103)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.53906"
+ y="217.78979"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="314.53906"
+ y="217.78979">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(33.388397,76.658478)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="315.78125"
+ y="270.48511"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="315.78125"
+ y="270.48511">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="344.92188"
+ y="267.43823"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="344.92188"
+ y="267.43823">record changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,128.5416)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.88281"
+ y="322.14166"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="314.88281"
+ y="322.14166">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="346.9086"
+ y="319.32135"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="346.9086"
+ y="319.32135">browse history</tspan></text>
+ <flowRoot
+ xml:space="preserve"
+ id="flowRoot2405"><flowRegion
+ id="flowRegion2407"><rect
+ id="rect2409"
+ width="274.35742"
+ height="94.045197"
+ x="293.44931"
+ y="485.2934" /></flowRegion><flowPara
+ id="flowPara2411"></flowPara></flowRoot> <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2427"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,180.5416)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.9375"
+ y="374.15729"
+ id="text2429"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2431"
+ x="314.9375"
+ y="374.15729">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="346.9086"
+ y="371.32135"
+ id="text2433"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2435"
+ x="346.9086"
+ y="371.32135">package release</tspan></text>
+ </g>
+</svg>
diff --git a/doc/en/user-guide/index-plain.txt b/doc/en/user-guide/index-plain.txt
new file mode 100644
index 0000000..a6dd8ab
--- /dev/null
+++ b/doc/en/user-guide/index-plain.txt
@@ -0,0 +1,120 @@
+#################
+Bazaar User Guide
+#################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+.. contents:: :depth: 3
+
+
+Introduction
+############
+
+.. include:: introducing_bazaar.txt
+.. include:: core_concepts.txt
+.. include:: bazaar_workflows.txt
+
+
+Getting started
+###############
+
+.. include:: installing_bazaar.txt
+.. include:: entering_commands.txt
+.. include:: getting_help.txt
+.. include:: configuring_bazaar.txt
+.. include:: using_aliases.txt
+.. include:: plugins.txt
+.. include:: zen.txt
+
+
+Personal version control
+########################
+
+.. include:: solo_intro.txt
+.. include:: starting_a_project.txt
+.. include:: controlling_registration.txt
+.. include:: reviewing_changes.txt
+.. include:: recording_changes.txt
+.. include:: browsing_history.txt
+.. include:: releasing_a_project.txt
+.. include:: undoing_mistakes.txt
+
+
+Sharing with peers
+##################
+
+.. include:: partner_intro.txt
+.. include:: branching_a_project.txt
+.. include:: merging_changes.txt
+.. include:: resolving_conflicts.txt
+.. include:: annotating_changes.txt
+
+
+Team collaboration, central style
+#################################
+
+.. include:: central_intro.txt
+.. include:: publishing_a_branch.txt
+.. include:: using_checkouts.txt
+.. include:: working_offline_central.txt
+.. include:: reusing_a_checkout.txt
+
+
+Team collaboration, distributed style
+#####################################
+
+.. include:: distributed_intro.txt
+.. include:: organizing_branches.txt
+.. include:: using_gatekeepers.txt
+.. include:: sending_changes.txt
+
+
+Miscellaneous topics
+####################
+
+.. include:: part2_intro.txt
+.. include:: adv_merging.txt
+.. include:: shelving_changes.txt
+.. include:: filtered_views.txt
+.. include:: stacked.txt
+.. include:: server.txt
+.. include:: hooks.txt
+.. include:: version_info.txt
+
+
+A brief tour of some popular plugins
+####################################
+
+.. include:: bzrtools_plugin.txt
+.. include:: svn_plugin.txt
+.. include later looms_plugin.txt
+
+
+Integrating Bazaar into your environment
+########################################
+
+.. include:: web_browsing.txt
+.. include later - file_explorers.txt
+.. include later - desktop_integration.txt
+.. include later - editors_and_ides.txt
+.. include later - email.txt
+.. include:: bug_trackers.txt
+
+
+Appendices
+##########
+
+.. include:: specifying_revisions.txt
+.. include:: organizing_your_workspace.txt
+.. include:: shared_repository_layouts.txt
+.. include:: setting_up_email.txt
+.. include:: http_smart_server.txt
+.. include:: writing_a_plugin.txt
+.. include:: licence.txt
+
+.. |--| unicode:: U+2014
+
diff --git a/doc/en/user-guide/index.txt b/doc/en/user-guide/index.txt
new file mode 100644
index 0000000..e9fe209
--- /dev/null
+++ b/doc/en/user-guide/index.txt
@@ -0,0 +1,143 @@
+#################
+Bazaar User Guide
+#################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+
+Introduction
+############
+
+.. toctree::
+ :maxdepth: 1
+
+ introducing_bazaar
+ core_concepts
+ bazaar_workflows
+
+
+Getting started
+###############
+
+.. toctree::
+ :maxdepth: 1
+
+ installing_bazaar
+ entering_commands
+ getting_help
+ configuring_bazaar
+ using_aliases
+ plugins
+ zen
+
+
+Personal version control
+########################
+
+.. toctree::
+ :maxdepth: 1
+
+ solo_intro
+ starting_a_project
+ controlling_registration
+ reviewing_changes
+ recording_changes
+ browsing_history
+ releasing_a_project
+ undoing_mistakes
+
+
+Sharing with peers
+##################
+
+.. toctree::
+ :maxdepth: 1
+
+ partner_intro
+ branching_a_project
+ merging_changes
+ resolving_conflicts
+ annotating_changes
+
+
+Team collaboration, central style
+#################################
+
+.. toctree::
+ :maxdepth: 1
+
+ central_intro
+ publishing_a_branch
+ using_checkouts
+ working_offline_central
+ reusing_a_checkout
+
+
+Team collaboration, distributed style
+#####################################
+
+.. toctree::
+ :maxdepth: 1
+
+ distributed_intro
+ organizing_branches
+ using_gatekeepers
+ sending_changes
+
+
+Miscellaneous topics
+####################
+
+.. toctree::
+ :maxdepth: 1
+
+ part2_intro
+ adv_merging
+ shelving_changes
+ filtered_views
+ stacked
+ server
+ hooks
+ version_info
+ gpg_signatures
+
+
+A brief tour of some popular plugins
+####################################
+
+.. toctree::
+ :maxdepth: 1
+
+ bzrtools_plugin
+ svn_plugin
+
+
+Integrating Bazaar into your environment
+########################################
+
+.. toctree::
+ :maxdepth: 1
+
+ web_browsing
+ bug_trackers
+
+
+Appendices
+##########
+
+.. toctree::
+ :maxdepth: 1
+
+ specifying_revisions
+ organizing_your_workspace
+ shared_repository_layouts
+ setting_up_email
+ http_smart_server
+ writing_a_plugin
+ licence
+
+.. |--| unicode:: U+2014
diff --git a/doc/en/user-guide/installing_bazaar.txt b/doc/en/user-guide/installing_bazaar.txt
new file mode 100644
index 0000000..035527d
--- /dev/null
+++ b/doc/en/user-guide/installing_bazaar.txt
@@ -0,0 +1,108 @@
+Installing Bazaar
+=================
+
+GNU/Linux
+---------
+
+Bazaar packages are available for most popular GNU/Linux distributions
+including Ubuntu, Debian, Red Hat and Gentoo.
+See http://wiki.bazaar.canonical.com/Download for the latest instructions.
+
+Windows
+-------
+
+For Windows users, an installer is available that includes
+the core Bazaar package together with necessary pre-requisites
+and some useful plug-ins.
+See http://wiki.bazaar.canonical.com/Download for the latest instructions.
+
+Note: If you are running Cygwin on Windows, a Bazaar for Cygwin package
+is available and ought to be used instead of the Windows version.
+
+Other operating systems
+-----------------------
+
+Beyond Linux and Windows, Bazaar packages are available for a large
+range of other operating systems include Mac OS X, FreeBSD and Solaris.
+See http://wiki.bazaar.canonical.com/Download for the latest instructions.
+
+
+Installing from scratch
+-----------------------
+
+If you wish to install Bazaar from scratch rather than using a
+pre-built package, the steps are:
+
+ 1. If it is not installed already, install Python 2.6 or later.
+
+ 2. Download the ``bazaar-xxx.tar.gz`` file (where xxx is the version
+ number) from http://wiki.bazaar.canonical.com/Download or from Launchpad
+ (https://launchpad.net/~bzr/).
+
+ 3. Unpack the archive using tar, WinZip or equivalent.
+
+ 4. Put the created directory on your PATH.
+
+To test the installation, try running the **bzr** command like this::
+
+ bzr version
+
+This will display the version of Bazaar you have installed. If this
+doesn't work, please contact us via email or IRC so we can help you
+get things working.
+
+
+Installing into site-wide locations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Instead of adding the directory to your PATH, you can install bzr into the
+system locations using::
+
+ python setup.py install
+
+If you do not have a compiler, or do not have the python development tools
+installed, bzr supplies a (slower) pure-python implementation of all
+extensions. You can install without compiling extensions with::
+
+ python setup.py install build_ext --allow-python-fallback
+
+
+
+Running the development version
+-------------------------------
+
+You may wish to always be using the very latest development version of
+Bazaar. Note that this is not recommended for
+the majority of users as there is an increased risk of bugs. On the other
+hand, the development version is remarkably solid (thanks to the processes
+we follow) and running it makes it easier for you to send us changes for
+bugs and improvements. It also helps us by having more people testing
+the latest software.
+
+Here are the steps to follow:
+
+ 1. Install Bazaar using one of the methods given above.
+
+ 2. Get a copy of the development version like this::
+
+ bzr branch lp:bzr
+
+ 3. Put the created directory on your PATH.
+
+Advanced users may also wish to build the optional C extensions for greater
+speed. This can be done using ``make`` and requires ``pyrex`` and a C compiler.
+Please contact us on email or IRC if you need assistance with this.
+
+
+Running multiple versions
+-------------------------
+
+It's easy to have multiple versions of Bazaar installed and to switch
+between them. To do this,
+simply provide the full pathname to the **bzr** command you wish to run.
+The relevant libraries will be automatically detected and used. Of course,
+if you do not provide a pathname, then the **bzr** used will be the one
+found on your system path as normal.
+
+Note that this capability is particularly useful if you wish to run
+(or test) both the latest released version and the development version say.
diff --git a/doc/en/user-guide/introducing_bazaar.txt b/doc/en/user-guide/introducing_bazaar.txt
new file mode 100644
index 0000000..e9be239
--- /dev/null
+++ b/doc/en/user-guide/introducing_bazaar.txt
@@ -0,0 +1,142 @@
+Introducing Bazaar
+==================
+
+What is Bazaar?
+---------------
+
+Bazaar is a tool for helping people collaborate. It tracks the changes
+that you and other people make to a group of files - such as software
+source code - to give you snapshots of each stage of their evolution.
+Using that information, Bazaar can effortlessly merge your work with
+other people's.
+
+Tools like Bazaar are called version control systems (VCS) and have
+long been popular with software developers. Bazaar's ease of use,
+flexibility and simple setup make it ideal not only for software
+developers but also for other groups who work together on files and
+documents, such as technical writers, web designers and translators.
+
+This guide takes you through installing Bazaar and how to use it,
+whether on your own or with a team of other people. If you're already
+familiar with distributed version control and want to dive straight in,
+you may wish to skim this section and jump straight to
+`Learning more`_.
+
+A brief history of version control systems
+------------------------------------------
+
+Version control tools have been evolving for several decades now. In
+simple terms, there have been 4 generations of tools:
+
+ 1. file versioning tools, e.g. SCCS, RCS
+ 2. tree versioning tools - central style, e.g. CVS
+ 3. tree versioning tools - central style, take two, e.g. Subversion
+ 4. tree versioning tools - distributed style, e.g. Bazaar.
+
+The design and implementation of Bazaar builds on the lessons learned
+from all the previous generations of tools. In particular, Bazaar
+cleanly supports both the central and the distributed version
+control models so you can change models as it makes sense, without
+needing to change tools.
+
+Central vs distributed VCS
+--------------------------
+
+Many traditional VCS tools require a central server which provides the
+change history or *repository* for a tree of files. To work on the files,
+users need to connect to the server and *checkout* the files. This gives
+them a directory or *working tree* in which a person can make changes.
+To record or *commit* these changes, the user needs access to the central
+server and they need to ensure they have merged their work with the latest
+version stored before trying to commit. This approach is known as the
+centralized model.
+
+The centralized model has proven useful over time but it can have some notable
+drawbacks. Firstly, a centralized VCS requires that one is able to connect
+to the server whenever one wants to do version control work. Secondly, the
+centralized model tightly links the act of **snapshotting** changes with the act
+of **publishing** those changes. This can be good in some circumstances but
+it has a negative influence on quality in others.
+
+Distributed VCS tools let users and teams have multiple repositories
+rather than just a single central one. In Bazaar's case, the history is
+normally kept in the same place as the code that is being version controlled.
+This allows the user to commit their changes whenever it makes sense, even
+when offline. Network access is only required when publishing changes or
+when accessing changes in another location.
+
+In fact, using distributed VCS tools wisely can have advantages well
+beyond the obvious one of disconnected operations for developers.
+Other advantages include:
+
+ * easier for developers to create experimental branches
+ * easier ad-hoc collaboration with peers
+ * less time required on mechanical tasks - more time for creativity
+
+ * increased release management flexibility through the use of
+ "feature-wide" commits
+
+ * trunk quality and stability can be kept higher, making everyone's
+ job less stressful
+
+ * in open communities:
+
+ * easier for non-core developers to create and maintain changes
+
+ * easier for core developers to work with non-core developers and
+ move them into the core
+
+ * in companies, easier to work with distributed and outsourced teams.
+
+For a detailed look at the advantages of distributed VCS tools over
+centralized VCS tools, see http://wiki.bazaar.canonical.com/BzrWhy.
+
+
+Key features of Bazaar
+----------------------
+
+While Bazaar is not the only distributed VCS tool around, it does have some
+notable features that make it an excellent choice for many teams and
+communities. A summary of these and comparisons with other VCS tools
+can be found on the Bazaar Wiki, http://wiki.bazaar.canonical.com.
+
+Of the many features, one in particular is worth highlighting:
+Bazaar is completely free software written in Python. As a result,
+it is easy to contribute improvements. If you wish to get involved,
+please see http://wiki.bazaar.canonical.com/BzrSupport.
+
+
+Learning more
+-------------
+
+This manual provides an easy to read introduction to Bazaar and how to use
+it effectively. It is recommended that all users read at least the rest of
+this chapter as it:
+
+ * explains the core concepts users need to know
+ * introduces some popular ways of using Bazaar to collaborate.
+
+Chapters 2-6 provide a closer look at how to use Bazaar to complete
+various tasks. It is recommended that most users read these in first-to-last
+order shortly after starting to use Bazaar. Chapter 7 and beyond provide
+additional information that helps you make the most of Bazaar once the core
+functionality is understood. This material can be read when required and in
+any order.
+
+If you are already familiar with other version control tools,
+you may wish to get started quickly by reading the following documents:
+
+ * `Bazaar in five minutes`_ - a mini-tutorial
+
+ * `Bazaar Quick Start Card`_ - a one page summary of commonly used commands.
+
+In addition, the online help and `Bazaar User Reference`_ provide all the
+details on the commands and options available.
+
+.. _Bazaar in five minutes: ../mini-tutorial/index.html
+.. _Bazaar Quick Start Card: ../quick-reference/index.html
+.. _Bazaar User Reference: ../user-reference/index.html
+
+We hope you find this manual useful. If you have suggestions on how it
+or the rest of Bazaar's documentation can be improved, please contact
+us on the mailing list, bazaar@lists.canonical.com.
diff --git a/doc/en/user-guide/licence.txt b/doc/en/user-guide/licence.txt
new file mode 100644
index 0000000..09af80e
--- /dev/null
+++ b/doc/en/user-guide/licence.txt
@@ -0,0 +1,7 @@
+Licence
+===============
+
+Copyright 2009-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
diff --git a/doc/en/user-guide/merging_changes.txt b/doc/en/user-guide/merging_changes.txt
new file mode 100644
index 0000000..4154108
--- /dev/null
+++ b/doc/en/user-guide/merging_changes.txt
@@ -0,0 +1,92 @@
+Merging changes
+===============
+
+Parallel development
+--------------------
+
+Once someone has their own branch of a project, they can make
+and commit changes in parallel to any development proceeding
+on the original branch. Pretty soon though, these independent
+lines of development will need to be combined again. This
+process is known as *merging*.
+
+The merge command
+-----------------
+
+To incorporate changes from another branch, use the ``merge`` command.
+Its syntax is::
+
+ bzr merge [URL]
+
+If no URL is given, a default is used, initially the branch this branch
+originated from.
+For example, if Bill made a branch from Mary's work, he can merge her
+subsequent changes by simply typing this::
+
+ bzr merge
+
+On the other hand, Mary might want to merge into her branch the work Bill
+has done in his. In this case, she needs to explicitly give the URL the
+first time, e.g.::
+
+ bzr merge bzr+ssh://mary@bill-laptop/cool-repo/cool-trunk
+
+This sets the default merge branch if one is not already set. Use
+``--no-remember`` to avoid setting it. To change the default after it is set,
+use the ``--remember`` option.
+
+How does merging work?
+----------------------
+
+A variety of algorithms exist for merging changes. Bazaar's
+default algorithm is a variation of *3-way merging* which
+works as follows. Given an ancestor A and two branches B and C,
+the following table provides the rules used.
+
+ === === === ====== =================
+ A B C Result Comment
+ === === === ====== =================
+ x x x x unchanged
+ x x y y line from C
+ x y x y line from B
+ x y z ? conflict
+ === === === ====== =================
+
+Note that some merges can only be completed with the assistance
+of a human. Details on how to resolve these are given in
+`Resolving conflicts <resolving_conflicts.html>`_.
+
+Recording a merge
+-----------------
+
+After any conflicts are resolved, the merge needs to be committed.
+For example::
+
+ bzr commit -m "Merged Mary's changes"
+
+Even if there are no conflicts, an explicit commit is still required.
+Unlike some other tools, this is considered a feature in Bazaar.
+A clean merge is not necessarily a good merge so making the commit
+a separate explicit step allows you to run your test suite first to
+verify all is good. If problems are found, you should correct them
+before committing the merge or throw the merge away using ``revert``.
+
+Merge tracking
+--------------
+
+One of the most important features of Bazaar is distributed,
+high quality *merge tracking*.
+In other words, Bazaar remembers what has been merged already and
+uses that information to intelligently choose the best ancestor for
+a merge, minimizing the number and size of conflicts.
+
+If you are a refugee from many other VCS tools, it can be really
+hard to "unlearn" the *please-let-me-avoid-merging-at-any-cost* habit.
+Bazaar lets you safely merge as often as you like with other people.
+By working in a peer-to-peer manner when it makes sense to do so, you
+also avoid using a central branch as an "integration swamp", keeping
+its quality higher. When the change you're collaborating on is
+truly ready for wider sharing, that's the time to merge and commit
+it to a central branch, not before.
+
+Merging that Just Works truly can change how developers work together.
diff --git a/doc/en/user-guide/organizing_branches.txt b/doc/en/user-guide/organizing_branches.txt
new file mode 100644
index 0000000..9444f15
--- /dev/null
+++ b/doc/en/user-guide/organizing_branches.txt
@@ -0,0 +1,100 @@
+Organizing branches
+===================
+
+Mirror branches
+---------------
+
+A primary difference when using distributed workflows to
+develop is that your main local branch is not the place
+to make changes. Instead, it is kept as a pristine copy
+of the central branch, i.e. it's a *mirror branch*.
+
+To create a mirror branch, set-up a shared repository
+(if you haven't already) and then use the ``branch``
+(or ``checkout``) command to create the mirror.
+For example::
+
+ bzr init-repo PROJECT
+ cd PROJECT
+ bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+Task branches
+-------------
+
+Each new feature or fix is developed in its own branch.
+These branches are referred to as *feature branches* or
+*task branches* - the terms are used interchangeably.
+
+To create a task branch, use the ``branch`` command
+against your mirror branch. For example::
+
+ bzr branch trunk fix-123
+ cd fix-123
+ (hack, hack, hack)
+
+There are numerous advantages to this approach:
+
+ 1. You can work on multiple changes in parallel
+ 2. There is reduced coupling between changes
+ 3. Multiple people can work in a peer-to-peer mode
+ on a branch until it is ready to go.
+
+In particular, some changes take longer to cook than others
+so you can ask for reviews, apply feedback, ask for another
+review, etc. By completing work to sufficient quality in
+separate branches before merging into a central branch, the
+quality and stability of the central branch are maintained
+at higher level than they otherwise would be.
+
+Refreshing a mirror branch
+--------------------------
+
+Use the ``pull`` command to do this::
+
+ cd trunk
+ bzr pull
+
+Merging the latest trunk into a feature branch
+----------------------------------------------
+
+Use the ``merge`` command to do this::
+
+ cd fix-123
+ bzr merge
+ (resolve any conflicts)
+ bzr commit -m "merged trunk"
+
+Merging a feature into the trunk
+--------------------------------
+
+The policies for different distributed workflows vary here.
+The simple case where all developers have commit rights to
+the main trunk are shown below.
+
+If your mirror is a checkout::
+
+ cd trunk
+ bzr update
+ bzr merge ../fix-123
+ (resolve any conflicts)
+ bzr commit -m "Fixed bug #123"
+
+If your mirror is a branch::
+
+ cd trunk
+ bzr pull
+ bzr merge ../fix-123
+ (resolve any conflicts)
+ bzr commit -m "Fixed bug #123"
+ bzr push
+
+Backing up task branches
+------------------------
+
+One of the side effects of centralized workflows is that changes
+get frequently committed to a central location which is backed up as
+part of normal IT operations. When developing on task branches,
+it is a good idea to publish your work to a central location
+(but not necessarily a shared location) that will be backed up.
+You may even wish to bind local task branches to remote ones
+established on a backup server just for this purpose.
diff --git a/doc/en/user-guide/organizing_your_workspace.txt b/doc/en/user-guide/organizing_your_workspace.txt
new file mode 100644
index 0000000..c053900
--- /dev/null
+++ b/doc/en/user-guide/organizing_your_workspace.txt
@@ -0,0 +1,176 @@
+Organizing your workspace
+=========================
+
+Common workspace layouts
+------------------------
+
+The best way for a Bazaar user to organize their workspace for a project
+depends on numerous factors including:
+
+* user role: project owner vs core developer vs casual contributor
+
+* workflows: particularly the workflow the project encourages/mandates
+ for making contributions
+
+* size: large projects have different resource requirements to small ones.
+
+There are at least 4 common ways of organizing one's workspace:
+
+* lightweight checkout
+* standalone tree
+* feature branches
+* switchable sandbox.
+
+A brief description of each layout follows.
+
+
+Lightweight checkout
+--------------------
+
+In this layout, the working tree is local and the branch is remote.
+This is the standard layout used by CVS and Subversion: it's simple
+and well understood.
+
+To set up::
+
+ bzr checkout --lightweight URL project
+ cd project
+
+To work::
+
+ (make changes)
+ bzr commit
+ (make changes)
+ bzr commit
+
+Note that each commit implicitly publishes the change to everyone else
+working from that branch. However, you need to be up to date with changes
+in the remote branch for the commit to succeed. To grab the latest code
+and merge it with your changes, if any::
+
+ bzr update
+
+
+Standalone tree
+---------------
+
+In this layout, the working tree & branch are in the one place. Unless
+a shared repository exists in a higher level directory, the repository
+is located in that same place as well. This is the default layout in
+Bazaar and it's great for small to moderately sized projects.
+
+To set up::
+
+ bzr branch URL project
+ cd project
+
+To work::
+
+ (make changes)
+ bzr commit
+ (make changes)
+ bzr commit
+
+To publish changes to a central location::
+
+ bzr push [URL]
+
+The URL for push is only required the first time.
+
+If the central location has, in the meantime, received changes from
+other users, then you'll need to merge those changes into your local
+branch before you try to push again::
+
+ bzr merge
+ (resolve conflicts)
+ bzr commit
+
+As an alternative, a checkout can be used. Like a branch, a checkout
+has a full copy of the history stored locally but the local branch
+is bound to the remote location so that commits are published to
+both locations at once.
+
+Note: A checkout is actually smarter than a local commit followed by
+a push. In particular, a checkout wil commit to the remote location
+first and only commit locally if the remote commit succeeds.
+
+
+Feature branches
+----------------
+
+In this layout, there are multiple branches/trees, typically sharing
+a repository. One branch is kept as a mirror of "trunk" and each
+unit-of-work (i.e. bug-fix or enhancement) gets its own "feature branch".
+This layout is ideal for most projects, particularly moderately sized ones.
+
+To set up::
+
+ bzr init-repo project
+ cd project
+ bzr branch URL trunk
+
+To start a feature branch::
+
+ bzr branch trunk featureX
+ cd featureX
+
+To work::
+
+ (make changes)
+ bzr commit
+ (make changes)
+ bzr commit
+
+To publish changes to a mailing list for review & approval::
+
+ bzr send
+
+To publish changes to a public branch (that can then be registered as
+a Launchpad merge request, say)::
+
+ bzr push [URL]
+
+As a variation, the trunk can be created as a checkout. If you have
+commit privileges on trunk, that lets you merge into trunk and the
+commit of the merge will implicitly publish your change. Alternatively,
+if the trunk URL is read-only (e.g. an HTTP address), that prevents
+accidental submission this way - ideal if the project workflow uses
+an automated gatekeeper like PQM, say.
+
+
+Local sandbox
+-------------
+
+This layout is very similar to the feature branches layout except that
+the feature branches share a single working tree rather than having one
+each. This is similar to git's default layout and it's useful for projects
+with really large trees (> 10000 files say) or for projects with lots of
+build artifacts (like .o or .class files).
+
+To set up::
+
+ bzr init-repo --no-trees project
+ cd project
+ bzr branch URL trunk
+ bzr checkout --lightweight trunk sandbox
+ cd sandbox
+
+While you *could* start making changes in sandbox now, committing while
+the sandbox is pointing to the trunk would mean that trunk is no longer
+a mirror of the upstream URL (well unless the trunk is a checkout).
+Therefore, you usually want to immediately create a feature branch and
+switch your sandbox to it like this::
+
+ bzr branch ../trunk ../featureX
+ bzr switch ../featureX
+
+The processes for making changes and submitting them are otherwise
+pretty much the same as those used for feature branches.
+
+
+Advanced layouts
+----------------
+
+If you wish, you can put together your own layout based on how **you** like
+things organized. See `Advanced shared repository layouts
+<shared_repository_layouts.html>`_ for examples and inspiration.
diff --git a/doc/en/user-guide/part2_intro.txt b/doc/en/user-guide/part2_intro.txt
new file mode 100644
index 0000000..175da6e
--- /dev/null
+++ b/doc/en/user-guide/part2_intro.txt
@@ -0,0 +1,16 @@
+The journey ahead
+=================
+
+We hope that earlier chapters have given you a solid
+understanding of how Bazaar can assist you in being productive
+on your own and working effectively with others.
+If you are learning Bazaar for the first time, it might be
+good to try the procedures covered already for a while,
+coming back to this manual once you have mastered them.
+
+Remaining chapters
+covers various topics to guide you in further optimizing how you
+use Bazaar. Unless stated otherwise, the topics in this and
+remaining chapters are independent of each other and can therefore
+be read in whichever order you wish.
+
diff --git a/doc/en/user-guide/partner_intro.txt b/doc/en/user-guide/partner_intro.txt
new file mode 100644
index 0000000..5511daf
--- /dev/null
+++ b/doc/en/user-guide/partner_intro.txt
@@ -0,0 +1,39 @@
+Working with another
+====================
+
+Peer-to-peer rocks
+------------------
+
+In many cases, two minds can be better than one. You may be the one
+who started a project and someone wishes to help, or perhaps it's you
+who wants to help another. Perhaps you are both members of a larger
+team that have been assigned a task together as pair programmers.
+Either way, two people need to agree on a process, a set of
+guidelines and a toolset in order to work together effectively.
+
+Imagine if you were not allowed to call someone on the phone directly
+and the only way to talk to them was by registering a conference call first?
+Companies and communities that only share code via a central VCS
+repository are living with a similar straitjacket to that every day.
+There are times when central control makes a lot of sense and times
+when peer-to-peer rocks. Either way, Bazaar is designed to help.
+
+The partner workflow
+--------------------
+
+While it's certainly not the only way to do it, the *partner workflow*
+below is a good starting point for a pair of people who wish to
+collaborate using Bazaar.
+
+.. image:: images/workflows_peer.png
+
+Over and above the tasks covered in the previous chapter, this
+chapter introduces two essential collaboration activities:
+
+ * getting a copy of a branch
+ * merging changes between branches.
+
+Even when it's just you working on a code base, it can be very useful
+to keep multiple branches around (for different releases say) and
+to merge changes between them as appropriate. Your "partner" may indeed
+be yourself.
diff --git a/doc/en/user-guide/plugins.txt b/doc/en/user-guide/plugins.txt
new file mode 100644
index 0000000..522e59a
--- /dev/null
+++ b/doc/en/user-guide/plugins.txt
@@ -0,0 +1,98 @@
+Using plugins
+=============
+
+.. Information on how to use plugins in Bazaar.
+
+What is a plugin?
+-----------------
+
+A plugin is an external component for Bazaar that is typically made by
+third parties. A plugin is capable of augmenting Bazaar by adding new
+functionality. A plugin can also change current Bazaar behavior by
+replacing current functionality. Sample applications of plugins are:
+
+* overriding commands
+* adding new commands
+* providing additional network transports
+* customizing log output.
+
+The sky is the limit for the customization that can be done through plugins.
+In fact, plugins often work as a way for developers to test new features for
+Bazaar prior to inclusion in the official codebase. Plugins are helpful
+at feature retirement time as well, e.g. deprecated file formats may one
+day be removed from the Bazaar core and be made available as a plugin instead.
+
+Plugins are good for users, good for external developers and good for
+Bazaar itself.
+
+Where to find plugins
+---------------------
+
+We keep our list of plugins on the http://wiki.bazaar.canonical.com/BzrPlugins page.
+
+How to install a plugin
+-----------------------
+
+Installing a plugin is very easy! If not already created, create a
+``plugins`` directory under your Bazaar configuration directory,
+``~/.bazaar/`` on Unix and
+``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\``
+on Windows. Within this directory (referred to as $BZR_HOME below),
+each plugin is placed in its own subdirectory.
+
+Plugins work particularly well with Bazaar branches. For example, to
+install the bzrtools plugins for your main user account on GNU/Linux,
+one can perform the following::
+
+ bzr branch http://panoramicfeedback.com/opensource/bzr/bzrtools
+ ~/.bazaar/plugins/bzrtools
+
+When installing plugins, the directories that you install them in must
+be valid python identifiers. This means that they can only contain
+certain characters, notably they cannot contain hyphens (``-``). Rather
+than installing ``bzr-gtk`` to ``$BZR_HOME/plugins/bzr-gtk``, install it
+to ``$BZR_HOME/plugins/gtk``.
+
+Alternative plugin locations
+----------------------------
+
+If you have the necessary permissions, plugins can also be installed on a
+system-wide basis. One can additionally override the personal plugins
+location by setting the environment variable ``BZR_PLUGIN_PATH`` (see `User
+Reference <../user-reference/configuration-help.html#bzr-plugin-path>`_
+for a detailed explanation).
+
+Listing the installed plugins
+-----------------------------
+
+To do this, use the plugins command like this::
+
+ bzr plugins
+
+The name, location and version of each plugin installed will be displayed.
+
+New commands added by plugins can be seen by running ``bzr help commands``.
+The commands provided by a plugin are shown followed by the name of the
+plugin in brackets.
+
+Popular plugins
+---------------
+
+Here is a sample of some of the more popular plugins.
+
+ ================ ================= ==================================
+ Category Name Description
+ ================ ================= ==================================
+ GUI QBzr Qt-based GUI tools
+ GUI bzr-gtk GTK-based GUI tools
+ GUI bzr-eclipse Eclipse integration
+ General bzrtools misc. enhancements including shelf
+ General difftools external diff tool helper
+ General extmerge external merge tool helper
+ Integration bzr-svn use Subversion as a repository
+ Migration cvsps migrate CVS patch-sets
+ ================ ================= ==================================
+
+If you wish to write your own plugins, it is not difficult to do.
+See `Writing a plugin <writing a plugin.html>`_ in the appendices to get
+started.
diff --git a/doc/en/user-guide/publishing_a_branch.txt b/doc/en/user-guide/publishing_a_branch.txt
new file mode 100644
index 0000000..754f20b
--- /dev/null
+++ b/doc/en/user-guide/publishing_a_branch.txt
@@ -0,0 +1,69 @@
+.. _publishing_a_branch:
+
+Publishing a branch
+===================
+
+Setting up a central repository
+-------------------------------
+
+While the centralized workflow can be used by socially nominating
+any branch on any computer as the central one, in practice most
+teams have a dedicated server for hosting central branches.
+
+Just as it's best practice to use a shared repository locally,
+it's advisable to put central branches in a shared repository.
+Note that central shared branches typically only want to
+store history, not working copies of files, so their enclosing
+repository is usually creating using the ``no-trees`` option, e.g.::
+
+ bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/PROJECT
+
+You can think of this step as similar to setting up a new cvsroot or
+Subversion repository. However, Bazaar gives you more flexibility
+in how branches may be organised in your repository. See
+`Advanced shared repository layouts <shared_repository_layouts.html>`_
+in the appendices for guidelines and examples.
+
+
+Starting a central branch
+-------------------------
+
+There are two ways of populating a central branch with some initial
+content:
+
+ 1. Making a local branch and pushing it to a central location
+ 2. Making an empty central branch then committing content to it.
+
+Here is an example of the first way::
+
+ bzr init-repo PROJECT (prepare local repository)
+ bzr init PROJECT/trunk
+ cd PROJECT/trunk
+ (copy development files)
+ cp -ar ~/PROJECT . (copy files in using OS-specific tools)
+ bzr add (populate repository; start version control)
+ bzr commit -m "Initial import"
+ (publish to central repository)
+ bzr push bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+Here is an example of the second way::
+
+ bzr init-repo PROJECT (prepare local repository)
+ cd PROJECT
+ bzr init bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+ bzr checkout bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+ cd trunk
+ cp -ar ~/PROJECT . (copy files in using OS-specific tools)
+ bzr add (populate repository; start version control)
+ bzr commit -m "Initial import"
+ (publish to central repository)
+
+Note that committing inside a working tree created using
+the ``checkout`` command implicitly commits the content to
+the central location as well as locally. Had we used the
+``branch`` command instead of ``checkout`` above, the
+content would have only been committed locally.
+
+Working trees that are tightly bound to a central location
+like this are called *checkouts*. The rest of this chapter
+explains their numerous features in more detail.
diff --git a/doc/en/user-guide/recording_changes.txt b/doc/en/user-guide/recording_changes.txt
new file mode 100644
index 0000000..265dce2
--- /dev/null
+++ b/doc/en/user-guide/recording_changes.txt
@@ -0,0 +1,81 @@
+Recording changes
+=================
+
+bzr commit
+----------
+
+When the working tree state is satisfactory, it can be **committed** to
+the branch, creating a new revision holding a snapshot of that state.
+
+The **commit** command takes a message describing the changes in the
+revision. It also records your userid, the current time and timezone, and
+the inventory and contents of the tree. The commit message is specified
+by the ``-m`` or ``--message`` option. You can enter a multi-line commit
+message; in most shells you can enter this just by leaving the quotes open
+at the end of the line.
+
+::
+
+ % bzr commit -m "added my first file"
+
+You can also use the ``-F`` option to take the message from a file. Some
+people like to make notes for a commit message while they work, then
+review the diff to make sure they did what they said they did. (This file
+can also be useful when you pick up your work after a break.)
+
+Message from an editor
+----------------------
+
+If you use neither the ``-m`` nor the ``-F`` option then bzr will open an
+editor for you to enter a message. The editor to run is controlled by
+your ``$VISUAL`` or ``$EDITOR`` environment variable, which can be overridden
+by the ``editor`` setting in ``~/.bazaar/bazaar.conf``; ``$BZR_EDITOR`` will
+override either of the above mentioned editor options. If you quit the
+editor without making any changes, the commit will be cancelled.
+
+The file that is opened in the editor contains a horizontal line. The part
+of the file below this line is included for information only, and will not
+form part of the commit message. Below the separator is shown the list of
+files that are changed in the commit. You should write your message above
+the line, and then save the file and exit.
+
+If you would like to see the diff that will be committed as you edit the
+message you can use the ``--show-diff`` option to ``commit``. This will include
+the diff in the editor when it is opened, below the separator and the
+information about the files that will be committed. This means that you can
+read it as you write the message, but the diff itself wont be seen in the
+commit message when you have finished. If you would like parts to be
+included in the message you can copy and paste them above the separator.
+
+Selective commit
+----------------
+
+If you give file or directory names on the commit command line then only
+the changes to those files will be committed. For example::
+
+ % bzr commit -m "documentation fix" commit.py
+
+By default bzr always commits all changes to the tree, even if run from a
+subdirectory. To commit from only the current directory down, use::
+
+ % bzr commit .
+
+Giving credit for a change
+--------------------------
+
+If you didn't actually write the changes that you are about to commit, for instance
+if you are applying a patch from someone else, you can use the ``--author`` commit
+option to give them credit for the change::
+
+ % bzr commit --author "Jane Rey <jrey@example.com>"
+
+The person that you specify there will be recorded as the "author" of the revision,
+and you will be recorded as the "committer" of the revision.
+
+If more than one person works on the changes for a revision, for instance if you
+are pair-programming, then you can record this by specifying ``--author`` multiple
+times::
+
+ % bzr commit --author "Jane Rey <jrey@example.com>" \
+ --author "John Doe <jdoe@example.com>"
+
diff --git a/doc/en/user-guide/releasing_a_project.txt b/doc/en/user-guide/releasing_a_project.txt
new file mode 100644
index 0000000..ffea469
--- /dev/null
+++ b/doc/en/user-guide/releasing_a_project.txt
@@ -0,0 +1,48 @@
+Releasing a project
+===================
+
+Packaging a release
+-------------------
+
+The ``export`` command is used to package a release, i.e. to
+take a copy of the files and directories in a branch and
+package them into a fresh directory or archive. For example,
+this command will package the last committed version into
+a ``tar.gz`` archive file::
+
+ bzr export ../releases/my-stuff-1.5.tar.gz
+
+The ``export`` command uses the suffix of the archive file
+to work out the type of archive to create as shown below.
+
+ ================= =========================
+ Supported formats Autodetected by extension
+ ================= =========================
+ dir (none)
+ tar .tar
+ tbz2 .tar.bz2, .tbz2
+ tgz .tar.gz, .tgz
+ zip .zip
+ ================= =========================
+
+If you wish to package a revision other than the last one, use
+the ``-r`` option. If you wish to tune the root directory inside
+the archive, use the ``--root`` option. See the online help or
+User Reference for further details on the options supported by
+``export``.
+
+Tagging a release
+-----------------
+
+Rather than remembering which version was used to package a release,
+it's useful to define a symbolic name for a version using the ``tag``
+command like this::
+
+ bzr tag version-1-5
+
+That tag can be used later whenever a revision identifier is
+required, e.g.::
+
+ bzr diff -r tag:version-1-5
+
+To see the list of tags defined in a branch, use the ``tags`` command.
diff --git a/doc/en/user-guide/resolving_conflicts.txt b/doc/en/user-guide/resolving_conflicts.txt
new file mode 100644
index 0000000..ff723df
--- /dev/null
+++ b/doc/en/user-guide/resolving_conflicts.txt
@@ -0,0 +1,83 @@
+Resolving conflicts
+===================
+
+Workflow
+--------
+
+Unlike some other tools that force you to resolve each conflict during
+the merge process, Bazaar merges as much as it can and then reports the
+conflicts. This can make conflict resolution easier because the contents
+of the whole post-merge tree are available to help you decide how things
+ought to be resolved. You may also wish to selectively run tests as you go
+to confirm each resolution or group or resolutions is good.
+
+Listing conflicts
+-----------------
+
+As well as being reported by the ``merge`` command, the list of outstanding
+conflicts may be displayed at any time by using the ``conflicts``
+command. It is also included as part of the output from the ``status``
+command.
+
+Resolving a conflict
+--------------------
+
+When a conflict is encountered, the ``merge`` command puts embedded
+markers in each file showing the areas it couldn't resolve. It also
+creates 3 files for each file with a conflict:
+
+ * foo.BASE
+ * foo.THIS
+ * foo.OTHER
+
+where ``foo`` is the name of the conflicted file.
+In many cases, you can resolve conflicts by simply manually editing
+each file in question, fixing the relevant areas and removing the
+conflict markers as you go.
+
+After fixing all the files in conflict, and removing the markers,
+ask Bazaar to mark them as resolved using the ``resolve`` command like this::
+
+ bzr resolve
+
+Alternatively, after fixing each file, you can mark it as resolved
+like this::
+
+ bzr resolve foo
+
+Among other things, the ``resolve`` command cleans up the BASE,
+THIS and OTHER files from your working tree.
+
+Using the remerge command
+-------------------------
+
+In some cases, you may wish to try a different merge algorithm on a
+given file. To do this, use the ``remerge`` command nominating
+the file like this::
+
+ bzr remerge --weave foo
+
+where ``foo`` is the file and ``weave`` is one of the available
+merge algorithms. This algorithm is particularly useful when a
+so-called ``criss-cross`` merge is detected, e.g. when two branches
+merge the same thing then merge each other. See the online help for
+``criss-cross`` and ``remerge`` for further details.
+
+Using external tools to resolve conflicts
+-----------------------------------------
+
+If you have a GUI tool you like using to resolve conflicts, be sure
+to install the *extmerge* plugin. Once installed, it can be used
+like this::
+
+ bzr extmerge foo
+
+where ``foo`` is the conflicted file. Rather than provide a list of
+files to resolve, you can give the ``--all`` option to implicitly
+specify all conflicted files.
+
+The ``extmerge`` command uses the tool specified by the
+``external_merge`` setting in your ``bazaar.conf`` file.
+If not set, it will look for some popular merge tools such
+as ``kdiff3`` or ``opendiff``, the latter being a command
+line interface to the FileMerge utility in OS X.
diff --git a/doc/en/user-guide/reusing_a_checkout.txt b/doc/en/user-guide/reusing_a_checkout.txt
new file mode 100644
index 0000000..f5d602b
--- /dev/null
+++ b/doc/en/user-guide/reusing_a_checkout.txt
@@ -0,0 +1,86 @@
+Reusing a checkout
+==================
+
+Motivation
+----------
+
+At times, it can be useful to have a single checkout as your
+sandbox for working on multiple branches. Some possible reasons
+for this include:
+
+ * saving disk space when the working tree is large
+ * developing in a fixed location.
+
+In many cases, working tree disk usage swamps the size of the
+``.bzr`` directory. If you want to work on multiple branches
+but can't afford the overhead of a full working tree for each,
+reusing a checkout across multiples branches is the way to go.
+
+On other occasions, the location of your sandbox might be
+configured into numerous development and testing tools. Once
+again, reusing a checkout across multiple branches can help.
+
+
+Changing where a branch is bound to
+-----------------------------------
+
+To change where a checkout is bound to, follow these steps:
+
+ 1. Make sure that any local changes have been committed
+ centrally so that no work is lost.
+
+ 2. Use the ``bind`` command giving the URL of the new
+ remote branch you wish to work on.
+
+ 3. Make your checkout a copy of the desired branch by using
+ the ``update`` command followed by the ``revert`` command.
+
+Note that simply binding to a new branch and running ``update``
+merges in your local changes, both committed and uncommitted. You need
+to decide whether to keep them or not by running either ``revert``
+or ``commit``.
+
+An alternative to the bind+update recipe is using the ``switch``
+command. This is basically the same as removing the existing
+branch and running ``checkout`` again on the new location, except
+that any uncommitted changes in your tree are merged in.
+
+Note: As ``switch`` can potentially throw away committed changes in
+order to make a checkout an accurate cache of a different bound branch,
+it will fail by design if there are changes which have been committed
+locally but are not yet committed to the most recently bound branch.
+To truly abandon these changes, use the ``--force`` option.
+
+
+Switching a lightweight checkout
+--------------------------------
+
+With a lightweight checkout, there are no local commits and ``switch``
+effectively changes which branch the working tree is associated with.
+One possible setup is to use a lightweight checkout in combination
+with a local tree-less repository. This lets you switch what you
+are working on with ease. For example::
+
+ bzr init-repo --no-trees PROJECT
+ cd PROJECT
+ bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+ bzr checkout --lightweight trunk my-sandbox
+ cd my-sandbox
+ (hack away)
+
+Note that trunk in this example will have a ``.bzr`` directory within it
+but there will be no working tree there as the branch was created in
+a tree-less repository. You can grab or create as many branches as you
+need there and switch between them as required. For example::
+
+ (assuming in my-sandbox)
+ bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/PROJECT-1.0 ../PROJECT-1.0
+ bzr switch ../PROJECT-1.0
+ (fix bug in 1.0)
+ bzr commit -m "blah, blah blah"
+ bzr switch ../trunk
+ (go back to working on the trunk)
+
+Note: The branches may be local only or they may be bound to
+remote ones (by creating them with ``checkout`` or by using ``bind``
+after creating them with ``branch``).
diff --git a/doc/en/user-guide/reviewing_changes.txt b/doc/en/user-guide/reviewing_changes.txt
new file mode 100644
index 0000000..0570cbf
--- /dev/null
+++ b/doc/en/user-guide/reviewing_changes.txt
@@ -0,0 +1,66 @@
+Reviewing changes
+=================
+
+Looking before you leap
+-----------------------
+
+Once you have completed some work, it's a good idea to review your changes
+prior to permanently recording it. This way, you can make sure you'll be
+committing what you intend to.
+
+Two bzr commands are particularly useful here: **status** and **diff**.
+
+bzr status
+----------
+
+The **status** command tells you what changes have been made to the
+working directory since the last revision::
+
+ % bzr status
+ modified:
+ foo
+
+``bzr status`` hides "boring" files that are either unchanged or ignored.
+The status command can optionally be given the name of some files or
+directories to check.
+
+bzr diff
+--------
+
+The **diff** command shows the full text of changes to all files as a
+standard unified diff. This can be piped through many programs such as
+''patch'', ''diffstat'', ''filterdiff'' and ''colordiff''::
+
+ % bzr diff
+ === added file 'hello.txt'
+ --- hello.txt 1970-01-01 00:00:00 +0000
+ +++ hello.txt 2005-10-18 14:23:29 +0000
+ @@ -0,0 +1,1 @@
+ +hello world
+
+
+With the ``-r`` option, the tree is compared to an earlier revision, or
+the differences between two versions are shown::
+
+ % bzr diff -r 1000.. # everything since r1000
+ % bzr diff -r 1000..1100 # changes from 1000 to 1100
+
+To see the changes introduced by a single revision, you can use the ``-c``
+option to diff.
+
+::
+
+ % bzr diff -c 1000 # changes from r1000
+ # identical to -r999..1000
+
+The ``--diff-options`` option causes bzr to run the external diff program,
+passing options. For example::
+
+ % bzr diff --diff-options --side-by-side foo
+
+Some projects prefer patches to show a prefix at the start of the path
+for old and new files. The ``--prefix`` option can be used to provide
+such a prefix.
+As a shortcut, ``bzr diff -p1`` produces a form that works with the
+command ``patch -p1``.
+
diff --git a/doc/en/user-guide/sending_changes.txt b/doc/en/user-guide/sending_changes.txt
new file mode 100644
index 0000000..2992c47
--- /dev/null
+++ b/doc/en/user-guide/sending_changes.txt
@@ -0,0 +1,71 @@
+Sending changes
+===============
+
+Motivation
+----------
+
+In many distributed development scenarios, it isn't always feasible for
+developers to share task branches by advertising their URLs.
+For example, a developer working on a laptop might take it home overnight
+so his/her task branches could well be inaccessible when a gatekeeper
+in another timezone wants to review or merge it.
+
+Bazaar provides a neat feature to assist here: *merge directives*.
+
+Understanding merge directives
+------------------------------
+
+You can think of a merge directive as a "mini branch" - just the
+new growth on a branch since it was created. It's a software
+patch showing what's new but with added intelligence: metadata
+like interim commits, renames and digital signatures.
+
+Another useful metaphor is a packet cake: a merge directive has a recipe
+together with the ingredients you need bundled inside it.
+To stretch the metaphor, the ingredients are all the metadata on the
+changes made to the branch; the recipe is instructions on how those
+changes ought to be merged, i.e. information for the ``merge`` command
+to use in selecting common ancestors.
+
+Regardless of how you think of them, merge directives are neat.
+They are easy to create, suitable for mailing around as attachments
+and can be processed much like branches can on the receiving end.
+
+Creating a merge directive
+--------------------------
+
+To create and optionally send a merge directive, use the ``send`` command.
+
+By default, ``send`` will email the merge directive to the "submission
+address" for the branch, which is typically the lead developer or the
+development mailing list.
+``send`` without options will create a merge directive, fire up your email
+tool and attach it, ready for you to add the explanatory text bit.
+(See the online help for ``send`` and
+`Configuration Settings <../user-reference/index.html#configuration-settings>`_
+in the User Reference for further details on how to configure this.)
+
+Most projects like people to add some explanation to the mail along with
+the patch, explaining the reason for the patch, and why it is done the way
+it is. This gives a reviewer some context before going into the
+line-by-line diff.
+
+Alternatively, if the ``--output`` (or ``-o``) option is given, ``send``
+will write the merge directive to a file, so you can mail it yourself,
+examine it, or save it for later use. If an output file of ``-`` is
+given, the directive is written to stdout. For example::
+
+ cd X-fix-123
+ bzr send -o ../fix-123.patch
+
+
+Applying a merge directive
+--------------------------
+
+Merge directives can be applied in much the same way as branches: by
+using the ``merge`` and ``pull`` commands.
+
+They can also be useful when communicating with upstream projects
+that don't use Bazaar. In particular, the preview of the overall
+change in a merge directive looks like a vanilla software patch, so
+they can be applied using ``patch -p0`` for example.
diff --git a/doc/en/user-guide/server.txt b/doc/en/user-guide/server.txt
new file mode 100644
index 0000000..bb26bb0
--- /dev/null
+++ b/doc/en/user-guide/server.txt
@@ -0,0 +1,105 @@
+Running a smart server
+======================
+
+Bazaar does not require a specialised server because it operates over HTTP, FTP
+or SFTP. There is an optional smart server that can be invoked over SSH, from
+inetd, or in a dedicated mode.
+
+Dumb servers
+------------
+
+We describe HTTP, FTP, SFTP and HTTP-WebDAV as "dumb" servers because they do
+not offer any assistance to Bazaar. If you make a Bazaar repository available
+over any of these protocols, Bazaar will allow you to read it remotely. Just
+enter the URL to the branch in the Bazaar command you are running.::
+
+ bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
+
+Bazaar supports writing over FTP, SFTP and (via a plugin) over HTTP-WebDAV.
+
+High-performance smart server
+-----------------------------
+
+The high-performance smart server (hpss) performs certain operations much faster
+than dumb servers are capable of. In future releases, the range of operations
+that are improved by using the smart server will increase as we continue to
+tune performance.
+
+To maintain the highest security possible, the current
+smart server provides read-only access by default. To
+enable read-write access, run it with ``--allow-writes``. When using
+the SSH access method, bzr automatically runs with the
+``--allow-writes`` option.
+
+The alternative ways of configuring a smart server are explained below.
+
+SSH
+~~~
+
+Using Bazaar over SSH requires no special configuration on the server; so long
+as Bazaar is installed on the server you can use ``bzr+ssh`` URLs, e.g.::
+
+ bzr log bzr+ssh://host/path/to/branch
+
+If `bzr` is not installed system-wide on the server you may need to explicitly
+tell the local `bzr` where to find the remote `bzr`::
+
+ BZR_REMOTE_PATH=~/bin/bzr bzr log bzr+ssh://host/path/to/branch
+
+The ``BZR_REMOTE_PATH`` environment variable adjusts how `bzr` will be
+invoked on the remote system. By default, just `bzr` will be invoked,
+which requires the `bzr` executable to be on the default search path. You can
+also set this permanently per-location in ``locations.conf``.
+
+Like SFTP, paths starting with ``~`` are relative to your home directory, e.g.
+``bzr+ssh://example.com/~/code/proj``. Additionally, paths starting with
+``~user`` will be relative to that user's home directory.
+
+inetd
+~~~~~
+
+This example shows how to run `bzr` with a dedicated user `bzruser`
+for a shared repository in ``/srv/bzr/repo`` which has a branch at
+``/srv/bzr/repo/branchname``.
+
+Running a Bazaar server from inetd requires an inetd.conf entry::
+
+ 4155 stream TCP nowait bzruser /usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/repo
+
+When running client commands, the URL you supply is a `bzr://` URL relative to
+the ``--directory`` option given in inetd.conf::
+
+ bzr log bzr://host/branchname
+
+If possible, paths starting with ``~`` and ``~user`` will be expanded as for
+``bzr+ssh``. Home directories outside the ``--directory`` specified to ``bzr
+serve`` will not be accessible.
+
+Dedicated
+~~~~~~~~~
+
+This mode has the same path and URL behaviour as the inetd mode. To
+run as a specific user, you should use ``su`` or login as that user.
+
+This example runs bzr on its official port number of `4155` and listens on all
+interfaces. This allows connections from anywhere in the world that can reach
+your machine on port `4155`.
+
+server::
+
+ bzr serve --directory=/srv/bzr/repo
+
+client::
+
+ bzr log bzr://host/branchname
+
+This example runs ``bzr serve`` on `localhost` port `1234`.
+
+server::
+
+ bzr serve --listen=localhost --port=1234 --directory=/srv/bzr/repo
+
+client::
+
+ bzr log bzr://localhost:1234/branchname
+
diff --git a/doc/en/user-guide/setting_up_email.txt b/doc/en/user-guide/setting_up_email.txt
new file mode 100644
index 0000000..1ae6513
--- /dev/null
+++ b/doc/en/user-guide/setting_up_email.txt
@@ -0,0 +1,106 @@
+Configuring email
+=================
+
+.. Description of the various ways to specify to Bazaar your email address for commits.
+
+Why set up an email address with Bazaar?
+----------------------------------------
+
+Bazaar stores the specified email address in revisions when they're
+created so that people can tell who committed which revisions. The
+email addresses are not verified, therefore they could be bogus, so
+you have to trust the people involved in your project. Additionally,
+the email address in a revision gives others a way to contact the
+author of a revision for credit and/or blame. :)
+
+How to set up your email address
+--------------------------------
+
+Bazaar will try to guess an email address based on your username and the
+hostname if none is set. This will probably not be what you want, so three
+ways exist to tell Bazaar what email to use:
+
+You can set your email in one of several configuration files. Like
+other configuration values, you can set it in ``bazaar.conf`` as a
+general setting. If you want to override the value for a particular
+branch, or set of branches, you can use ``locations.conf``.
+``.bzr/branch/branch.conf`` will also work, but will cause all commits
+to that branch to use the same email address, even if someone else
+does them.
+
+The order of precedence is
+
+ 1. If the ``BZR_EMAIL`` environment variable is set.
+ #. If an email is set for your current branch in the ``locations.conf``
+ file.
+ #. If an email is set four your current branch in the
+ ``.bzr/branch/branch.conf`` file.
+ #. If an email is set in the ``bazaar.conf`` default configuration file.
+ #. If the `EMAIL` environment variable is set.
+ #. Bazaar will try to guess based on your username and the hostname.
+
+To check on what Bazaar thinks your current email is, use the ``whoami``
+("who am i?") command::
+
+ % bzr whoami
+ Joe Cool <joe@example.com>
+
+Setting email via the 'whoami' command
+--------------------------------------
+
+You can use the whoami command to set your email globally::
+
+ % bzr whoami "Joe Cool <joe@example.com>"
+
+or only for the current branch::
+
+ % bzr whoami --branch "Joe Cool <joe@example.com>"
+
+These modify your global ``bazaar.conf`` or branch ``branch.conf`` file, respectively.
+
+Setting email via default configuration file
+--------------------------------------------
+
+To use the default ini file, create or edit the ``bazaar.conf`` file (in
+``~/.bazaar/`` on Unix and in ``%APPDATA%\bazaar\2.0\`` in Windows)
+and set an email address as shown below. Please note that the word DEFAULT
+is case sensitive, and must be in upper-case.
+::
+
+ [DEFAULT]
+ email=Your Name <name@isp.com>
+
+
+For more information on the ini file format, see `Configuration Settings`_ in
+the Bazaar User Reference.
+
+.. _Configuration Settings: ../user-reference/index.html#configuration-settings
+
+Setting email on a per-branch basis
+-----------------------------------
+
+The second approach is to set email on a branch by branch basis by
+using the ``locations.conf`` configuration file like this::
+
+ [/some/branch/location]
+ email=Your Name <name@other-isp.com>
+
+This will set your email address in the branch at ``/some/branch/location``,
+overriding the default specified in the ``bazaar.conf`` above.
+
+Setting email via environment variable
+--------------------------------------
+The final method Bazaar will use is checking for the ``BZR_EMAIL``
+and ``EMAIL`` environment variables. Generally, you would use this
+method to override the email in a script context. If you would like
+to set a general default, then please see the ini methods above.
+
+Concerns about spam
+-------------------
+Some people want to avoid sharing their email address so as not to get
+spam. Bazaar will never disclose your email address, unless you publish
+a branch or changeset in a public location. It's recommended that you
+*do* use a real address, so that people can contact you about your work,
+but it's not required. You can use an address which is obfuscated, which
+bounces, or which goes through an anti-spam service such as
+`spamgourmet.com`.
diff --git a/doc/en/user-guide/shared_repository_layouts.txt b/doc/en/user-guide/shared_repository_layouts.txt
new file mode 100644
index 0000000..ad76b9a
--- /dev/null
+++ b/doc/en/user-guide/shared_repository_layouts.txt
@@ -0,0 +1,364 @@
+Advanced shared repository layouts
+==================================
+
+Bazaar is designed to give you flexibility in how you layout branches inside a shared repository.
+This flexibility allows users to tailor Bazaar to their workflow,
+but it also leads to questions about what is a "good" layout.
+We present some alternatives and give some discussion about the benefits of each.
+
+One key point which should be mentioned is that any good layout should somehow highlight
+what branch a "general" user should grab. In SVN this is deemed the "``trunk/``" branch,
+and in most of the layouts this naming convention is preserved. Some would call this
+"``mainline``" or "``dev``", and people from CVS often refer to this as "``HEAD``".
+
+
+"SVN-Style" (``trunk/``, ``branches/``)
+---------------------------------------
+
+Most people coming from SVN will be familiar with their "standard" project layout.
+Which is to layout the repository as::
+
+ repository/ # Overall repository
+ +- trunk/ # The mainline of development
+ +- branches/ # A container directory
+ | +- foo/ # Branch for developing feature foo
+ | ...
+ +- tags/ # Container directory
+ +- release-X # A branch specific to mark a given release version
+ ...
+
+With Bazaar, that is a perfectly reasonable layout.
+It has the benefit of being familiar to people coming from SVN,
+and making it clear where the development focus is.
+
+When you have multiple projects in the same repository,
+the SVN layout is a little unclear what to do.
+
+
+``project/trunk``
+~~~~~~~~~~~~~~~~~
+
+The preferred method for SVN seems to be to give each project a top level directory for a layout like::
+
+ repository/ # Overall repository
+ +- project1/ # A container directory
+ | +- trunk/ # The mainline of development of project1
+ | +- branches/ # A container directory
+ | +- foo/ # Branch for developing feature foo of project1
+ | ...
+ |
+ +- project2/ # Container for project2
+ +- trunk/ # Mainline for project2
+ +- branches/ # Container for project2 branches
+
+
+This also works with Bazaar.
+However, with Bazaar repositories are cheap to create
+(a simple ``bzr init-repo`` away), and their primary benefit is when the
+branches share a common ancestry.
+
+So the preferred way for Bazaar would be::
+
+ project1/ # A repository for project1
+ +- trunk/ # The mainline of development of project1
+ +- branches/ # A container directory
+ +- foo/ # Branch for developing feature foo of project1
+ ...
+
+ project2/ # A repository for project2
+ +- trunk/ # Mainline for project2
+ +- branches/ # Container for project2 branches
+
+
+``trunk/project``
+~~~~~~~~~~~~~~~~~
+
+There are also a few projects who use this layout in SVN::
+
+ repository/ # Overall repository
+ +- trunk/ # A container directory
+ | +- project1 # Mainline for project 1
+ | +- project2 # Mainline for project 2
+ | ...
+ |
+ +- branches/ # Container
+ +- project1/ # Container (?)
+ | +- foo # Branch 'foo' of project1
+ +- project2/
+ +- bar # Branch 'bar' of project2
+
+
+A slight variant is::
+
+ repository/ # Overall repository
+ +- trunk/ # A container directory
+ | +- project1 # Mainline for project 1
+ | +- project2 # Mainline for project 2
+ | ...
+ |
+ +- branches/ # Container
+ +- project1-foo/ # Branch 'foo' of project1
+ +- project2-bar/ # Branch 'bar' of project2
+
+I believe the reason for this in SVN, is so that someone
+can checkout all of "``trunk/``" and get the all the mainlines for all projects.
+
+This layout can be used for Bazaar, but it is not generally recommended.
+
+ 1) ``bzr branch/checkout/get`` is a single branch at a time.
+ So you don't get the benefit of getting all mainlines with a single command. [1]_
+
+ 2) It is less obvious of whether ``repository/trunk/foo`` is the ``trunk`` of project
+ ``foo`` or it is just the ``foo`` directory in the ``trunk`` branch.
+ Some of this confusion is due to SVN, because it uses the same "namespace"
+ for files in a project that it uses for branches of a project.
+ In Bazaar, there is a clear distinction of what files make up a project, versus
+ the location of the Branch. (After all, there is only one ``.bzr/`` directory per branch,
+ versus many ``.svn/`` directories in the checkout).
+
+.. [1] Note: `NestedTreeSupport`_ can provide a way to create "meta-projects" which
+ aggregate multiple projects regardless of the repository layout.
+ Letting you ``bzr checkout`` one project, and have it grab all the necessary
+ sub-projects.
+
+.. _NestedTreeSupport: http://wiki.bazaar.canonical.com/NestedTrees
+
+
+Nested Style (``project/branch/sub-branch/``)
+---------------------------------------------
+
+Another style with Bazaar, which is not generally possible in SVN
+is to have branches nested within each-other.
+This is possible because Bazaar supports (and recommends) creating repositories
+with no working trees (``--no-trees``).
+With a ``--no-trees`` repository, because the working files are not intermixed with
+your branch locations, you are free to put a branch in whatever namespace you want.
+
+One possibility is::
+
+ project/ # The overall repository, *and* the project's mainline branch
+ + joe/ # Developer Joe's primary branch of development
+ | +- feature1/ # Developer Joe's feature1 development branch
+ | | +- broken/ # A staging branch for Joe to develop feature1
+ | +- feature2/ # Joe's feature2 development branch
+ | ...
+ + barry/ # Barry's development branch
+ | ...
+ + releases/
+ +- 1.0/
+ +- 1.1.1/
+
+The idea with this layout is that you are creating a hierarchical layout for branches.
+Where changes generally flow upwards in the namespace. It also gives people a little
+corner of the namespace to work on their stuff.
+One nice feature of this layout, is it makes branching "cheaper" because it gives you
+a place to put all the mini branches without cluttering up the global ``branches/`` namespace.
+
+The other power of this is that you don't have to repeat yourself when specifying more detail in the
+branch name.
+
+For example compare::
+
+ bzr branch http://host/repository/project/branches/joe-feature-foo-bugfix-10/
+
+Versus::
+
+ bzr branch http://host/project/joe/foo/bugfix-10
+
+
+Also, if you list the ``repository/project/branches/`` directory you might see something like::
+
+ barry-feature-bar/
+ barry-bugfix-10/
+ barry-bugfix-12/
+ joe-bugfix-10/
+ joe-bugfix-13/
+ joe-frizban/
+
+Versus having these broken out by developer.
+If the number of branches are small, ``branches/`` has the nice advantage
+of being able to see all branches in a single view.
+If the number of branches is large, ``branches/`` has the distinct disadvantage
+of seeing all the branches in a single view (it becomes difficult to find the
+branch you are interested in, when there are 100 branches to look through).
+
+Nested branching seems to scale better to larger number of branches.
+However, each individual branch is less discoverable.
+(eg. "Is Joe working on bugfix 10 in his feature foo branch, or his feature bar branch?")
+
+One other small advantage is that you can do something like::
+
+ bzr branch http://host/project/release/1/1/1
+ or
+ bzr branch http://host/project/release/1/1/2
+
+To indicate release 1.1.1 and 1.1.2. This again depends on how many releases you have
+and whether the gain of splitting things up outweighs the ability to see more at a glance.
+
+
+Sorted by Status (``dev/``, ``merged/``, ``experimental/``)
+-----------------------------------------------------------
+
+One other way to break up branches is to sort them by their current status.
+So you would end up with a layout something like::
+
+ project/ # Overall layout
+ +- trunk/ # The development focus branch
+ +- dev/ # Container directory for in-progress work
+ | +- joe-feature1 # Joe's current feature-1 branch
+ | +- barry-bugfix10 # Barry's work for bugfix 10
+ | ...
+ +- merged/ # Container indicating these branches have been merged
+ | +- bugfix-12 # Bugfix which has already been merged.
+ +- abandonded/ # Branches which are considered 'dead-end'
+
+
+This has a couple benefits and drawbacks.
+It lets you see what branches are actively being developed on, which is usually
+only a small number, versus the total number of branches ever created.
+Old branches are not lost (versus deleting them), but they are "filed away",
+such that the more likely you are to want a branch the easier it is to find.
+(Conversely, older branches are likely to be harder to find).
+
+The biggest disadvantage with this layout, is that branches move around.
+Which means that if someone is following the ``project/dev/new-feature`` branch,
+when it gets merged into ``trunk/`` suddenly ``bzr pull`` doesn't mirror the branch
+for them anymore because the branch is now at ``project/merged/new-feature``.
+There are a couple ways around this. One is to use HTTP redirects to point people
+requesting the old branch to the new branch. ``bzr`` >= 0.15 will let users know
+that ``http://old/path redirects to http://new/path``. However, this doesn't help
+if people are accessing a branch through methods other than HTTP (SFTP, local filesystem, etc).
+
+It would also be possible to use a symlink for temporary redirecting (as long as the symlink
+is within the repository it should cause little trouble). However eventually you want to
+remove the symlink, or you don't get the clutter reduction benefit.
+Another possibility instead of a symlink is to use a ``BranchReference``. It is currently
+difficult to create these through the ``bzr`` command line, but if people find them useful
+that could be changed.
+This is actually how `Launchpad`_ allows you to ``bzr checkout https://launchpad.net/bzr``.
+Effectively a ``BranchReference`` is a symlink, but it allows you to reference any other URL.
+If it is extended to support relative references, it would even work over HTTP, SFTP,
+and local paths.
+
+.. _Launchpad: https://launchpad.net
+
+
+Sorted by date/release/etc (``2006-06/``, ``2006-07/``, ``0.8/``, ``0.9``)
+--------------------------------------------------------------------------
+
+Another method of allowing some scalability while also allowing the
+browsing of "current" branches. Basically, this works on the assumption
+that actively developed branches will be "new" branches, and older branches
+are either merged or abandoned.
+
+Basically the date layout looks something like::
+
+ project/ # Overall project repository
+ +- trunk/ # General mainline
+ +- 2006-06/ # containing directory for branches created in this month
+ | +- feature1/ # Branch of "project" for "feature1"
+ | +- feature2/ # Branch of "project" for "feature2"
+ +- 2005-05/ # Containing directory for branches create in a different month
+ +- feature3/
+ ...
+
+This answers the question "Where should I put my new branch?" very quickly.
+If a feature is developed for a long time, it is even reasonable to copy a
+branch into the newest date, and continue working on it there.
+Finding an active branch generally means going to the newest date, and
+going backwards from there. (A small disadvantage is that most directory
+listings sort oldest to the top, which may mean more scrolling).
+If you don't copy old branches to newer locations, it also has the disadvantage
+that searching for a branch may take a while.
+
+Another variant is by release target::
+
+ project/ # Overall repository
+ +- trunk/ # Mainline development branch
+ +- releases/ # Container for release branches
+ | +- 0.8/ # The branch for release 0.8
+ | +- 0.9/ # The branch for release 0.9
+ +- 0.8/ # Container for branches targeting release 0.8
+ | +- feature1/ # Branch for "feature1" which is intended to be merged into 0.8
+ | +- feature2/ # Branch for "feature2" which is targeted for 0.8
+ +- 0.9/
+ +- feature3/ # Branch for "feature3", targeted for release 0.9
+
+
+Some possible variants include having the ``0.9`` directory imply
+that it is branched *from* 0.9 rather than *for* 0.9, or having the ``0.8/release``
+as the official release 0.8 branch.
+
+The general idea is that by targeting a release, you can look at what branches are
+waiting to be merged. It doesn't necessarily give you a good idea of what the
+state of the branch (is it in development or finished awaiting review).
+It also has a history-hiding effect, and otherwise has the same benefits
+and deficits as a date-based sorting.
+
+
+Simple developer naming (``project/joe/foo``, ``project/barry/bar``)
+--------------------------------------------------------------------
+
+Another possibly layout is to give each developer a directory, and then
+have a single sub-directory for branches. Something like::
+
+ project/ # Overall repository
+ +- trunk/ # Mainline branch
+ +- joe/ # A container for Joe's branches
+ | +- foo/ # Joe's "foo" branch of "project"
+ +- barry/
+ +- bar/ # Barry's "bar" branch of "project"
+
+The idea is that no branch is "nested" underneath another one, just that each developer
+has his/her branches grouped together.
+
+A variant which is used by `Launchpad`_ is::
+
+ repository/
+ +- joe/ # Joe's branches
+ | +- project1/ # Container for Joe's branches of "project1"
+ | | +- foo/ # Joe's "foo" branch of "project1"
+ | +- project2/ # Container for Joe's "project2" branches
+ | +- bar/ # Joe's "bar" branch of "project2"
+ | ...
+ |
+ +- barry/
+ | +- project1/ # Container for Barry's branches of "project1"
+ | +- bug-10/ # Barry's "bug-10" branch of "project1"
+ | ...
+ +- group/
+ +- project1/
+ +- trunk/ # The main development focus for "project1"
+
+
+This lets you easily browse what each developer is working on. Focus branches
+are kept in a "group" directory, which lets you see what branches the "group"
+is working on.
+
+This keeps different people's work separated from each-other, but also makes it
+hard to find "all branches for project X". `Launchpad`_ compensates for this
+by providing a nice web interface with a database back end, which allows a
+"view" to be put on top of this layout.
+This is closer to the model of people's home pages, where each person has a
+"``~/public_html``" directory where they can publish their own web-pages.
+In general, though, when you are creating a shared repository for centralization
+of a project, you don't want to split it up by person and then project.
+Usually you would want to split it up by project and then by person.
+
+
+Summary
+-------
+
+In the end, no single naming scheme will work for everyone. It depends a lot on
+the number of developers, how often you create a new branch, what sort of
+lifecycles your branches go through. Some questions to ask yourself:
+
+ 1) Do you create a few long-lived branches, or do you create lots of "mini" feature branches
+ (Along with this is: Would you *like* to create lots of mini feature branches, but can't
+ because they are a pain in your current VCS?)
+
+ 2) Are you a single developer, or a large team?
+
+ 3) If a team, do you plan on generally having everyone working on the same branch at the same
+ time? Or will you have a "stable" branch that people are expected to track.
+
diff --git a/doc/en/user-guide/shelving_changes.txt b/doc/en/user-guide/shelving_changes.txt
new file mode 100644
index 0000000..b43101c
--- /dev/null
+++ b/doc/en/user-guide/shelving_changes.txt
@@ -0,0 +1,110 @@
+Shelving Changes
+================
+
+Sometimes you will want to temporarily remove changes from your working
+tree and restore them later, For instance to commit a small bug-fix you
+found while working on something. Bazaar allows you to put changes on
+a ``shelf`` to achieve this. When you want to restore the changes later
+you can use ``unshelve`` to apply them to your working tree again.
+
+For example, consider a working tree with one or more changes made ... ::
+
+ $ bzr diff
+ === modified file 'description.txt'
+ --- description.txt
+ +++ description.txt
+ @@ -2,7 +2,7 @@
+ ===============
+
+ These plugins
+ -by Michael Ellerman
+ +written by Michael Ellerman
+ provide a very
+ fine-grained 'undo'
+ facility
+ @@ -11,6 +11,6 @@
+ This allows you to
+ undo some of
+ your changes,
+ -commit, and get
+ +perform a commit, and get
+ back to where you
+ were before.
+
+The ``shelve`` command interactively asks which changes
+you want to retain in the working tree::
+
+ $ bzr shelve
+ --- description.txt
+ +++ description.txt
+ @@ -2,7 +2,7 @@
+ ===============
+
+ These plugins
+ -by Michael Ellerman
+ +written by Michael Ellerman
+ provide a very
+ fine-grained 'undo'
+ facility
+
+ Shelve? [yNfrq?]: y
+ --- description.txt
+ +++ description.txt
+ @@ -11,6 +11,6 @@
+ This allows you to
+ undo some of
+ your changes,
+ -commit, and get
+ +perform a commit, and get
+ back to where you
+ were before.
+
+ Shelve? [yNfrq?]: n
+ Shelve 2 change(s)? [yNfrq?]', 'y'
+ Selected changes:
+ M description.txt
+ Changes shelved with id "1".
+
+If there are lots of changes in the working tree, you
+can provide the ``shelve`` command with a list of files
+and you will only be asked about changes in those files.
+After shelving changes, it's a good idea to use ``diff``
+to confirm the tree has just the changes you expect::
+
+ $ bzr diff
+ === modified file 'description.txt'
+ --- description.txt
+ +++ description.txt
+ @@ -2,7 +2,7 @@
+ ===============
+
+ These plugins
+ -by Michael Ellerman
+ +written by Michael Ellerman
+ provide a very
+ fine-grained 'undo'
+ facility
+
+Great - you're ready to commit::
+
+ $ bzr commit -m "improve first sentence"
+
+At some later time, you can bring the shelved changes back into the
+working tree using ``unshelve``::
+
+ $ bzr unshelve
+ Unshelving changes with id "1".
+ M description.txt
+ All changes applied successfully.
+
+If you want to, you can put multiple items on the shelf.
+Normally each time you run ``unshelve`` the most recently
+shelved changes will be reinstated. However, you can also
+unshelve changes in a different order by explicitly
+specifying which changes to unshelve.
+
+Bazaar merges the changes in to your working tree, so they
+will apply even if you have edited the files since you shelved
+them, though they may conflict, in which case you will have to
+resolve the conflicts in the same way you do after a conflicted
+merge.
diff --git a/doc/en/user-guide/solo_intro.txt b/doc/en/user-guide/solo_intro.txt
new file mode 100644
index 0000000..4d48d32
--- /dev/null
+++ b/doc/en/user-guide/solo_intro.txt
@@ -0,0 +1,28 @@
+Going solo
+==========
+
+A personal productivity tool
+----------------------------
+
+Some tools are designed to make individuals productive (e.g. editors)
+while other tools (e.g. back-end services) are focused on making teams
+or whole companies more productive. Version control tools have
+traditionally been in the latter camp.
+
+One of the cool things about Bazaar is that it is so easy to setup
+that version control can now be treated as a personal productivity tool.
+If you wish to record changes to files for the purposes of checkpointing
+good known states or tracking history, it is now easy to do so. This
+chapter explains how.
+
+The solo workflow
+-----------------
+
+If you are creating your own masterpiece, whether that be a software
+project or a set of related documents, the typical workflow looks like this:
+
+.. image:: images/workflows_single.png
+
+Even if you will always be working as part of a team, the tasks covered
+in this chapter will be the basis of what you'll be doing so it's a good
+place to start.
diff --git a/doc/en/user-guide/specifying_revisions.txt b/doc/en/user-guide/specifying_revisions.txt
new file mode 100644
index 0000000..63a0a1a
--- /dev/null
+++ b/doc/en/user-guide/specifying_revisions.txt
@@ -0,0 +1,159 @@
+Specifying revisions
+====================
+
+Revision identifiers and ranges
+-------------------------------
+
+Bazaar has a very expressive way to specify a revision or a range of revisions.
+To specify a range of revisions, the upper and lower bounds are separated by the
+``..`` symbol. For example::
+
+ $ bzr log -r 1..4
+
+You can omit one bound like::
+
+ $ bzr log -r 1..
+ $ bzr log -r ..4
+
+Some commands take only one revision, not a range. For example::
+
+ $ bzr cat -r 42 foo.c
+
+In other cases, a range is required but you want the length of the range to
+be one. For commands where this is relevant, the ``-c`` option is used like this::
+
+ $ bzr diff -c 42
+
+
+Available revision identifiers
+------------------------------
+
+The revision, or the bounds of the range, can be given using
+different format specifications as shown below.
+
+ +----------------------+------------------------------------+
+ | argument type | description |
+ +----------------------+------------------------------------+
+ | *number* | revision number |
+ +----------------------+------------------------------------+
+ | **revno**:*number* | revision number |
+ +----------------------+------------------------------------+
+ | **last**:*number* | negative revision number |
+ +----------------------+------------------------------------+
+ | *guid* | globally unique revision id |
+ +----------------------+------------------------------------+
+ | **revid**:*guid* | globally unique revision id |
+ +----------------------+------------------------------------+
+ | **before**:*rev* | leftmost parent of ''rev'' |
+ +----------------------+------------------------------------+
+ | *date-value* | first entry after a given date |
+ +----------------------+------------------------------------+
+ | **date**:*date-value*| first entry after a given date |
+ +----------------------+------------------------------------+
+ | *tag-name* | revision matching a given tag |
+ +----------------------+------------------------------------+
+ | **tag**:*tag-name* | revision matching a given tag |
+ +----------------------+------------------------------------+
+ | **ancestor**:*path* | last merged revision from a branch |
+ +----------------------+------------------------------------+
+ | **branch**:*path* | latest revision on another branch |
+ +----------------------+------------------------------------+
+ | **submit**:*path* | common ancestor with submit branch |
+ +----------------------+------------------------------------+
+
+A brief introduction to some of these formats is given below.
+For complete details, see `Revision Identifiers`_ in the
+Bazaar User Reference.
+
+.. _Revision Identifiers: ../user-reference/index.html#revision-identifiers
+
+Numbers
+~~~~~~~
+
+Positive numbers denote revision numbers in the current branch. Revision
+numbers are labelled as "revno" in the output of ``bzr log``. To display
+the log for the first ten revisions::
+
+ $ bzr log -r ..10
+
+Negative numbers count from the latest revision, -1 is the last committed
+revision.
+
+To display the log for the last ten revisions::
+
+ $ bzr log -r -10..
+
+revid
+~~~~~
+
+**revid** allows specifying an internal revision ID, as shown by ``bzr
+log --show-ids`` and some other commands.
+
+For example::
+
+ $ bzr log -r revid:Matthieu.Moy@imag.fr-20051026185030-93c7cad63ee570df
+
+before
+~~~~~~
+
+**before**
+ ''rev'' specifies the leftmost parent of ''rev'', that is the revision
+ that appears before ''rev'' in the revision history, or the revision that
+ was current when ''rev'' was committed.
+
+''rev'' can be any revision specifier and may be chained.
+
+For example::
+
+ $ bzr log -r before:before:4
+ ...
+ revno: 2
+ ...
+
+date
+~~~~
+
+**date**
+ ''value'' matches the first history entry after a given date, either at
+ midnight or at a specified time.
+
+Legal values are:
+
+ * **yesterday**
+ * **today**
+ * **tomorrow**
+ * A **YYYY-MM-DD** format date.
+ * A **YYYY-MM-DD,HH:MM:SS** format date/time, seconds are optional (note the
+ comma)
+
+The proper way of saying "give me all the log entries for today" is::
+
+ $ bzr log -r date:yesterday..date:today
+
+Ancestor
+~~~~~~~~
+
+**ancestor**:*path*
+ specifies the common ancestor between the current branch and a
+ different branch. This is the same ancestor that would be used for
+ merging purposes.
+
+*path* may be the URL of a remote branch, or the file path to a local branch.
+
+For example, to see what changes were made on a branch since it was forked
+off ``../parent``::
+
+ $ bzr diff -r ancestor:../parent
+
+Branch
+~~~~~~
+
+branch
+ ``path`` specifies the latest revision in another branch.
+
+``path`` may be the URL of a remote branch, or the file path to a local branch.
+
+For example, to get the differences between this and another branch::
+
+ $ bzr diff -r branch:http://example.com/bzr/foo.dev
+
diff --git a/doc/en/user-guide/stacked.txt b/doc/en/user-guide/stacked.txt
new file mode 100644
index 0000000..bedc089
--- /dev/null
+++ b/doc/en/user-guide/stacked.txt
@@ -0,0 +1,136 @@
+Using stacked branches
+======================
+
+Motivation
+----------
+
+If you are working on a project, and you have read access to whose
+public repository but do not have write access to it, using stacked
+branches to backup/publish your work onto the same host of the public
+repository might be an option for you.
+
+Other scenarios for stacked branch usage include experimental branches
+and code hosting sites. For these scenarios, stacked branches are
+ideal because of the benefits it provides.
+
+
+What is a stacked branch?
+-------------------------
+
+A stacked branch is a branch that knows how to find revisions in
+another branch (the stacked-on branch). Stacked branches store just
+the unique revisions that are not in the stacked-on branch, making
+them faster to create and more storage efficient. In these respects,
+stacked branches are similar to shared repositories. However, stacked
+branches have additional benefits:
+
+* The new branch can be in a completely different location to the
+ branch being stacked on.
+
+* Deleting the stacked branch really deletes the revisions (rather
+ than leaving them in a shared repository).
+
+* Security is improved over shared repositories, because the stacked-on
+ repository can be physically readonly to developers committing to stacked
+ branches.
+
+
+Creating a stacked branch
+-------------------------
+
+To create a stacked branch, use the ``stacked`` option of the branch command.
+For example::
+
+ bzr branch --stacked source-url my-dir
+
+This will create ``my-dir`` as a stacked branch with no local revisions.
+If it is defined, the public branch associated with ``source-url`` will be
+used as the *stacked-on* location. Otherwise, ``source-url`` will be the
+*stacked-on* location.
+
+
+Creating a stacked checkout
+---------------------------
+
+Direct creation of a stacked checkout is expected to be supported soon.
+In the meantime, a two step process is required:
+
+1. Create a stacked branch as shown above.
+
+2. Convert the branch into a checkout using either the ``reconfigure``
+ or ``bind`` command.
+
+
+Pushing a stacked branch
+------------------------
+
+Most changes on most projects build on an existing branch such as the
+*development trunk* or *current stable* branch. Creating a new
+branch stacked on one of these is easy to do using the ``push``
+command like this::
+
+ bzr push --stacked-on reference-url my-url
+
+This creates a new branch at ``my-url`` that is stacked on ``reference-url``
+and only contains the revisions in the current branch that are not already
+in the branch at ``reference-url``. In particular, ``my-url`` and
+``reference-url`` can be on the same host, and the ``--stacked-on`` option
+can be used additionally to inform ``push`` to reference the
+revisions in ``reference-url``. For example::
+
+ bzr push --stacked-on bzr+ssh://host/project bzr+ssh://host/user/stacked-branch
+
+This usage fits the scenario described in the Motivation section.
+
+You can also use the ``--stacked`` option without specifying ``--stacked-on``.
+This will automatically set the *stacked-on* location to the parent branch of
+the branch you are pushing (or its ``public_location`` if configured). For
+example::
+
+ bzr branch source-url my-dir
+ cd my-dir
+ (hack, hack, hack)
+ bzr commit -m "fix bug"
+ bzr push --stacked
+
+You can combine ``bzr branch --stacked`` and ``bzr push --stacked`` to work on a
+branch without downloading or uploading the whole history::
+
+ bzr branch --stacked source-url my-dir
+ cd my-dir
+ (hack, hack, hack)
+ bzr commit -m "fix bug"
+ bzr push --stacked
+
+
+Limitations of stacked branches
+-------------------------------
+
+The important thing to remember about a stacked branch is that the stacked-on
+branch needs to be accessible for almost all operations. This is not an issue
+when both branches are local, or when both branches are on the same server and
+the stacked-on location is a relative path. But clearly a branch hosted on a
+server with a stacked-on location of ``file:///...`` is not going to work for
+anyone except the user that originally pushed it. It's a good idea to configure
+``public_location`` to help prevent that.
+
+Similarly, because most of the history is stored in the stacked-on repository,
+operations like ``bzr log`` can be slower when the stacked-on repository is
+accessed via a network.
+
+If a stacked branch is in a format older than 2a, you cannot commit to it due to
+`bug 375013`_.
+
+.. _bug 375013: https://bugs.launchpad.net/bzr/+bug/375013
+
+
+Changing branch stacking
+------------------------
+
+Stacking of existing branches can be changed using the ``bzr reconfigure``
+command to either stack on an existing branch, or to turn off stacking.
+Be aware that when ``bzr reconfigure --unstacked`` is used, bzr will
+copy all the referenced data from the stacked-on repository into the
+previously stacked repository. For large repositories this may take
+considerable time and may substantially increase the size of the
+repository.
diff --git a/doc/en/user-guide/starting_a_project.txt b/doc/en/user-guide/starting_a_project.txt
new file mode 100644
index 0000000..9e896df
--- /dev/null
+++ b/doc/en/user-guide/starting_a_project.txt
@@ -0,0 +1,55 @@
+Starting a project
+==================
+
+Putting an existing project under version control
+-------------------------------------------------
+
+If you already have a tree of source code (or directory of documents) you
+wish to put under version control, here are the commands to use::
+
+ cd my-stuff
+ bzr init
+ bzr add
+ bzr commit -m "Initial import"
+
+``bzr init`` creates a ``.bzr`` directory in the top level directory
+(``my-stuff`` in the example above). Note that:
+
+ * Bazaar has everything it needs in that directory - you do
+ **not** need to setup a database, web server or special service
+ to use it
+
+ * Bazaar is polite enough to only create one ``.bzr`` in the
+ directory given, not one in every subdirectory thereof.
+
+``bzr add`` then finds all the files and directories it thinks
+ought to be version controlled and registers them internally.
+``bzr commit`` then records a snapshot of the content of these
+and records that information, together with a commit message.
+
+More information on ``init``, ``add`` and ``commit`` will be provided
+later. For now, the important thing to remember is the recipe above.
+
+Starting a new project
+----------------------
+
+If you are starting a project from scratch, you can also use the recipe
+above, after creating an empty directory first of course. For efficiency
+reasons that will be explored more in later chapters though, it is a good
+idea to create a repository for the project at the top level and to nest
+a *main* branch within it like this::
+
+ bzr init-repo my.repo
+ cd my.repo
+ bzr init my.main
+ cd my.main
+ hack, hack, hack
+ bzr add
+ bzr commit -m "Initial import"
+
+Some users prefer a name like *trunk* or *dev* to *main*. Choose
+whichever name makes the most sense to you.
+
+Note that the ``init-repo`` and ``init`` commands both take a path as an
+argument and will create that path if it doesn't already exist.
+
diff --git a/doc/en/user-guide/svn_plugin.txt b/doc/en/user-guide/svn_plugin.txt
new file mode 100644
index 0000000..530f365
--- /dev/null
+++ b/doc/en/user-guide/svn_plugin.txt
@@ -0,0 +1,114 @@
+bzr-svn
+=======
+
+Overview
+--------
+
+bzr-svn lets developers use Bazaar as their VCS client on projects
+still using a central Subversion repository. Access to Subversion
+repositories is largely transparent, i.e. you can use most ``bzr``
+commands directly on Subversion repositories exactly the same
+as if you were using ``bzr`` on native Bazaar branches.
+
+Many bzr-svn users create a local mirror of the central Subversion
+trunk, work in local feature branches, and submit their
+overall change back to Subversion when it is ready
+to go. This lets them gain many of the advantages of distributed
+VCS tools without interrupting existing team-wide processes and
+tool integration hooks currently built on top of Subversion. Indeed,
+this is a common interim step for teams looking to adopt Bazaar but
+who are unable to do so yet for timing or non-technical reasons.
+
+For installation instructions, see the bzr-svn home page:
+http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion.
+
+
+A simple example
+----------------
+
+Here's a simple example of how you can use bzr-svn to hack on a
+GNOME project like **beagle**. Firstly, setup a local shared repository
+for storing your branches in and checkout the trunk::
+
+ bzr init-repo beagle-repo
+ cd beagle-repo
+ bzr checkout svn+ssh://svn.gnome.org/svn/beagle/trunk beagle-trunk
+
+Next, create a feature branch and hack away::
+
+ bzr branch beagle-trunk beagle-feature1
+ cd beagle-feature1
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+
+When the feature is cooked, refresh your trunk mirror and merge
+your change::
+
+ cd ../beagle-trunk
+ bzr update
+ bzr merge ../beagle-feature1
+ bzr commit -m "Complete comment for SVN commit"
+
+As your trunk mirror is a checkout, committing to it implicitly
+commits to the real Subversion trunk. That's it!
+
+
+Using a central repository mirror
+---------------------------------
+
+For large projects, it often makes sense to tweak the recipe given above.
+In particular, the initial checkout can get quite slow so you may wish
+to import the Subversion repository into a Bazaar one once and for all
+for your project, and then branch from that native Bazaar repository
+instead. bzr-svn provides the ``svn-import`` command for doing this
+repository-to-repository conversion. Here's an example of how to use it::
+
+ bzr svn-import svn+ssh://svn.gnome.org/svn/beagle
+
+Here's the recipe from above updated to use a central Bazaar mirror::
+
+ bzr init-repo beagle-repo
+ cd beagle-repo
+ bzr branch bzr+ssh://bzr.gnome.org/beagle.bzr/trunk beagle-trunk
+ bzr branch beagle-trunk beagle-feature1
+ cd beagle-feature1
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+ cd ../beagle-trunk
+ bzr pull
+ bzr merge ../beagle-feature1
+ bzr commit -m "Complete comment for SVN commit"
+ bzr push
+
+In this case, committing to the trunk only commits the merge locally.
+To commit back to the master Subversion trunk, an additional command
+(``bzr push``) is required.
+
+Note: You'll need to give ``pull`` and ``push`` the relevant URLs
+the first time you use those commands in the trunk branch. After that,
+bzr remembers them.
+
+The final piece of the puzzle in this setup is to put scripts in
+place to keep the central Bazaar mirror synchronized with the Subversion
+one. This can be done by adding a cron job, using a Subversion hook,
+or whatever makes sense in your environment.
+
+
+Limitations of bzr-svn
+----------------------
+
+Bazaar and Subversion are different tools with different capabilities
+so there will always be some limited interoperability issues.
+Here are some examples current as of bzr-svn 0.5.4:
+
+ * Bazaar doesn't support versioned properties
+
+ * Bazaar doesn't support tracking of file copies.
+
+See the bzr-svn web page,
+http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion,
+for the current list of constraints.
diff --git a/doc/en/user-guide/undoing_mistakes.txt b/doc/en/user-guide/undoing_mistakes.txt
new file mode 100644
index 0000000..48ea658
--- /dev/null
+++ b/doc/en/user-guide/undoing_mistakes.txt
@@ -0,0 +1,168 @@
+Undoing mistakes
+================
+
+Mistakes happen
+---------------
+
+Bazaar has been designed to make it easy to
+recover from mistakes as explained below.
+
+Dropping the revision history for a project
+-------------------------------------------
+
+If you accidentally put the wrong tree under version control, simply
+delete the ``.bzr`` directory.
+
+Deregistering a file or directory
+---------------------------------
+
+If you accidentally register a file using ``add`` that you
+don't want version controlled, you can use the ``remove``
+command to tell Bazaar to forget about it.
+
+``remove`` has been designed to *Do the Safe Thing* in
+that it will not delete a modified file. For example::
+
+ bzr add foo.html
+ (oops - didn't mean that)
+ bzr remove foo.html
+
+This will complain about the file being modified or unknown.
+If you want to keep the file, use the ``--keep`` option.
+Alternatively, if you want to delete the file, use the ``--force`` option.
+For example::
+
+ bzr add foo.html
+ (oops - didn't mean that)
+ bzr remove --keep foo.html
+ (foo.html left on disk, but deregistered)
+
+On the other hand, the unchanged ``TODO`` file is deregistered and
+removed from disk without complaint in this example::
+
+ bzr add TODO
+ bzr commit -m "added TODO"
+ (hack, hack, hack - but don't change TODO)
+ bzr remove TODO
+ (TODO file deleted)
+
+Note: If you delete a file using your file manager, IDE or via an operating
+system command, the ``commit`` command will implicitly treat it as removed.
+
+Undoing changes since the last commit
+-------------------------------------
+
+One of the reasons for using a version control tool is that it
+lets you easily checkpoint good tree states while working. If you
+decide that the changes you have made since the last ``commit`` ought
+to be thrown away, the command to use is ``revert`` like this::
+
+ bzr revert
+
+As a precaution, it is good practice to use ``bzr status`` and
+``bzr diff`` first to check that everything being thrown away
+really ought to be.
+
+Undoing changes to a file since the last commit
+-----------------------------------------------
+
+If you want to undo changes to a particular file since the last commit but
+keep all the other changes in the tree, pass the filename as an argument
+to ``revert`` like this::
+
+ bzr revert foo.py
+
+Undoing the last commit
+-----------------------
+
+If you make a commit and really didn't mean to, use the ``uncommit`` command
+to undo it like this::
+
+ bzr uncommit
+
+Unlike ``revert``, ``uncommit`` leaves the content of your working tree
+exactly as it is. That's really handy if you make a commit and accidently
+provide the wrong error message. For example::
+
+ bzr commit -m "Fix bug #11"
+ (damn - wrong bug number)
+ bzr uncommit
+ bzr commit -m "Fix bug #1"
+
+Another common reason for undoing a commit is because you forgot to add
+one or more files. Some users like to alias ``commit`` to ``commit --strict``
+so that commits fail if unknown files are found in the tree.
+
+Tags for uncommitted revisions are removed from the branch unless
+``--keep-tags`` was specified.
+
+Note: While the ``merge`` command is not introduced until the next
+chapter, it is worth noting now that ``uncommit`` restores any pending
+merges. (Running ``bzr status`` after ``uncommit`` will show these.)
+``merge`` can also be used to effectively undo just a selected commit
+earlier in history. For more information on ``merge``, see
+`Merging changes <merging_changes.html>`_ in the next chapter and the
+Bazaar User Reference.
+
+Undoing multiple commits
+------------------------
+
+You can use the -r option to undo several commits like this::
+
+ bzr uncommit -r -3
+
+If your reason for doing this is that you really want to
+back out several changes, then be sure to remember that ``uncommit``
+does not change your working tree: you'll probably need to run the
+``revert`` command as well to complete the task. In many cases though,
+it's arguably better to leave your history alone and add a new
+revision reflecting the content of the last good state.
+
+Reverting to the state of an earlier version
+--------------------------------------------
+
+If you make an unwanted change but it doesn't make sense to uncommit
+it (because that code has been released to users say), you can use
+``revert`` to take your working tree back to the desired state.
+For example::
+
+ % bzr commit "Fix bug #5"
+ Committed revision 20.
+ (release the code)
+ (hmm - bad fix)
+ bzr revert -r 19
+ bzr commit -m "Backout fix for bug #5"
+
+This will change your entire tree back to the state as of revision 19,
+which is probably only what you want if you haven't made any new commits
+since then. If you have, the ``revert`` would wipe them out as well. In that
+case, you probably want to use `Reverse cherrypicking
+<adv_merging.html#reverse-cherrypicking>`_ instead to
+back out the bad fix.
+
+Note: As an alternative to using an absolute revision number (like 19), you can
+specify one relative to the tip (-1) using a negative number like this::
+
+ bzr revert -r -2
+
+Correcting a tag
+----------------
+
+If you have defined a tag prematurely, use the ``--force`` option of
+the ``tag`` command to redefine it. For example::
+
+ bzr tag 2.0-beta-1
+ (oops, we're not yet ready for that)
+ (make more commits to include more fixes)
+ bzr tag 2.0-beta-1 --force
+
+Clearing a tag
+--------------
+
+If you have defined a tag and no longer want it defined, use the
+``--delete`` option of the ``tag`` command to remove it. For example::
+
+ bzr tag 2.0-beta-4
+ (oops, we're not releasing a 4th beta)
+ bzr tag 2.0-beta-4 --delete
+
diff --git a/doc/en/user-guide/using_aliases.txt b/doc/en/user-guide/using_aliases.txt
new file mode 100644
index 0000000..7afd005
--- /dev/null
+++ b/doc/en/user-guide/using_aliases.txt
@@ -0,0 +1,63 @@
+Using aliases
+=============
+
+What are aliases?
+-----------------
+
+Aliases are an easy way to create shortcuts for commonly-typed commands, or to set
+defaults for commands.
+
+Defining aliases
+----------------
+
+Command aliases can be defined in the ``[ALIASES]`` section of your
+``bazaar.conf`` file. Aliases start with the alias name, then an
+equal sign, then a command fragment. Here's an example ALIASES section::
+
+ [ALIASES]
+ recentlog=log -r-3..-1
+ ll=log --line -r-10..-1
+ commit=commit --strict
+ diff=diff --diff-options -p
+
+Here are the explanations of the examples above:
+
+ * The first alias makes a new ``recentlog`` command that shows the logs for the
+ last three revisions
+ * The ``ll`` alias shows the last 10 log entries in line format.
+ * the ``commit`` alias sets the default for commit to refuse to commit if new
+ files in the tree are not recognized.
+ * the ``diff`` alias adds the coveted -p option to diff
+
+Using the aliases
+-----------------
+
+The aliases defined above would be used like so: ::
+
+ % bzr recentlog
+ % bzr ll
+ % bzr commit
+ % bzr diff
+
+Rules for aliases
+-----------------
+
+ * You can override a portion of the options given in an alias by
+ specifying the new part on the command-line. For example, if
+ you run ``lastlog -r-5..``, you will only get five line-based log
+ entries instead of 10. Note that all boolean options have an
+ implicit inverse, so you can override the commit alias with
+ ``commit --no-strict``.
+
+ * Aliases can override the standard behaviour of existing commands by giving
+ an alias name that is the same as the original command. For example, default
+ commit is changed with ``commit=commit --strict``.
+
+ * Aliases cannot refer to other aliases. In other words making a
+ ``lastlog`` alias and referring to it with a ``ll`` alias will not work.
+ This includes aliases that override standard commands.
+
+ * Giving the ``--no-aliases`` option to the bzr command will tell it to ignore aliases
+ for that run. For example, running ``bzr --no-aliases commit`` will perform a
+ standard commit instead, not do a ``commit --strict``.
+
diff --git a/doc/en/user-guide/using_checkouts.txt b/doc/en/user-guide/using_checkouts.txt
new file mode 100644
index 0000000..dfd8e62
--- /dev/null
+++ b/doc/en/user-guide/using_checkouts.txt
@@ -0,0 +1,97 @@
+Using checkouts
+===============
+
+Turning a branch into a checkout
+--------------------------------
+
+If you have a local branch and wish to make it a checkout, use the
+``bind`` command like this::
+
+ bzr bind bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+This is necessary, for example, after creating a central branch using
+``push`` as illustrated in the previous section.
+
+After this, commits will be applied to the bound branch before
+being applied locally.
+
+Turning a checkout into a branch
+--------------------------------
+
+If you have a checkout and wish to make it a normal branch, use the
+``unbind`` command like this::
+
+ bzr unbind
+
+After this, commits will only be applied locally.
+
+Getting a checkout
+------------------
+
+When working in a team using a central branch, one person needs
+to provide some initial content as shown in the previous section.
+After that, each person should use the ``checkout`` command to
+create their local checkout, i.e. the sandbox in which they
+will make their changes.
+
+Unlike Subversion and CVS, in Bazaar the ``checkout`` command creates a
+local full copy of history in addition to creating a working tree holding
+the latest content. This means that operations such as ``diff`` and ``log``
+are fast and can still be used when disconnected from the central location.
+
+Getting a lightweight checkout
+------------------------------
+
+While Bazaar does its best to efficiently store version history, there
+are occasions when the history is simply not wanted. For example, if your
+team is managing the content of a web site using Bazaar with a
+central repository, then your release process might be as simple as
+updating a checkout of the content on the public web server. In this
+case, you probably don't want the history downloaded to that location
+as doing so:
+
+ * wastes disk space holding history that isn't needed there
+ * exposes a Bazaar branch that you may want kept private.
+
+To get a history-less checkout in Bazaar, use the ``--lightweight``
+option like this::
+
+ bzr checkout --lightweight bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+Of course, many of the benefits of a normal checkout are lost by doing
+this but that's a tradeoff you can make if and when it makes sense.
+
+The ``--lightweight`` option only applies to checkouts, not to all branches.
+
+Note: If your code base is really large and disk space on your computer
+is limited, lightweight checkouts may be the right choice for you.
+Be sure to consider all your options though including
+`shared repositories <branching_a_project.html#a-reminder-about-shared-repositories>`_,
+`stacked branches <stacked.html>`_, and
+`reusing a checkout <reusing_a_checkout.html>`_.
+
+Updating to the latest content
+------------------------------
+
+One of the important aspects of working in lockstep with others is
+keeping your checkout up to date with the latest changes made to
+the central branch. Just as you would in Subversion or CVS, you do
+this in Bazaar by using the ``update`` command like this::
+
+ bzr update
+
+This gets any new revisions available in the bound branch and
+merges your local changes, if any.
+
+Handling commit failures
+------------------------
+
+Note that your checkout *must* be up to date with the bound branch
+before running ``commit``. Bazaar is actually stricter about this
+than Subversion or CVS - you need to be up to date with the full
+tree, not just for the files you've changed. Bazaar will ask you
+to run ``update`` if it detects that a revision has been added to
+the central location since you last updated.
+
+If the network connection to the bound branch is lost, the commit will
+fail. Some alternative ways of working around that are outlined next.
diff --git a/doc/en/user-guide/using_gatekeepers.txt b/doc/en/user-guide/using_gatekeepers.txt
new file mode 100644
index 0000000..06d3d58
--- /dev/null
+++ b/doc/en/user-guide/using_gatekeepers.txt
@@ -0,0 +1,44 @@
+Using gatekeepers
+=================
+
+The decentralized with human gatekeeper workflow
+------------------------------------------------
+
+In this workflow, one developer (the gatekeeper) has commit rights
+to the main branch while other developers have read-only access.
+All developers make their changes in task branches.
+
+.. image:: images/workflows_gatekeeper.png
+
+When a developer wants their work merged, they ask the gatekeeper
+to review their change and merge it if acceptable. If a change fails
+review, further development proceeds in the relevant task branch
+until it is good to go.
+
+Note that a key aspect of this approach is the inversion of control
+that is implied: developers no longer decide when to "commit/push"
+changes into the central branch: the code base evolves by gatekeepers
+"merging/pulling" changes in a controlled manner. It's perfectly
+acceptable, indeed common, to have multiple central branches with
+different gatekeepers, e.g. one branch for the current production
+release and another for the next release. In this case, a task branch
+holding a bug fix will most likely be advertised to both gatekeepers.
+
+One of the great things about this workflow is that it is hugely
+scalable. Large projects can be broken into teams and each
+team can have a *local master branch* managed by a gatekeeper.
+Someone can be appointed as the primary gatekeeper to merge
+changes from the team master branches into the primary master
+branch when team leaders request it.
+
+The decentralized with automatic gatekeeper workflow
+----------------------------------------------------
+
+To obtain even higher quality, all developers can be required to
+submit changes to an automated gatekeeper that only merges and
+commits a change if it passes a regression test suite. One
+such gatekeeper is a software tool called PQM.
+
+.. image:: images/workflows_pqm.png
+
+For further information on PQM, see https://launchpad.net/pqm.
diff --git a/doc/en/user-guide/version_info.txt b/doc/en/user-guide/version_info.txt
new file mode 100644
index 0000000..88a9964
--- /dev/null
+++ b/doc/en/user-guide/version_info.txt
@@ -0,0 +1,108 @@
+Exporting version information
+=============================
+
+Getting the last revision number
+--------------------------------
+
+If you only need the last revision number in your build scripts, you can
+use the ``revno`` command to get that value like this::
+
+ $ bzr revno
+ 3104
+
+
+Getting more version information
+--------------------------------
+
+The ``version-info`` command can be used to output more information
+about the latest version like this::
+
+ $ bzr version-info
+ revision-id: pqm@pqm.ubuntu.com-20071211175118-s94sizduj201hrs5
+ date: 2007-12-11 17:51:18 +0000
+ build-date: 2007-12-13 13:14:51 +1000
+ revno: 3104
+ branch-nick: bzr.dev
+
+You can easily filter that output using operating system tools or
+scripts. For example::
+
+ $ bzr version-info | grep ^date
+ date: 2007-12-11 17:51:18 +0000
+
+The ``--all`` option will actually dump version information about
+every revision if you need that information for more advanced
+post-processing.
+
+
+Python projects
+---------------
+
+.. TODO: Figure out how to attach into ``setup.py``
+
+
+If using a Makefile to build your project, you can generate the version
+information file as simply as::
+
+ library/_version.py:
+ bzr version-info --format python > library/_version.py
+
+This generates a file which contains 3 dictionaries:
+
+ * `version_info`: A dictionary containing the basic information about the
+ current state.
+
+ * `revisions`: A dictionary listing all of the revisions in the
+ history of the tree, along with the commit times and commit
+ message. This defaults to being empty unless ``--all`` or
+ ``--include-history`` is supplied. This is useful if you want to
+ track what bug fixes, etc, might be included in the released
+ version. But for many projects it is more information than needed.
+
+ * `file_revisions`: A dictionary listing the last-modified revision
+ for all files in the project. This can be used similarly to how
+ ``$Id$`` keywords are used in CVS-controlled files. The last
+ modified date can be determined by looking in the ``revisions``
+ map. This is also empty by default, and enabled only by ``--all``
+ or ``--include-file-revisions``.
+
+
+Getting version info in other formats
+-------------------------------------
+
+Bazaar supports a template-based method for getting version information in
+arbitrary formats. The ``--custom`` option to ``version-info`` can be
+used by providing a ``--template`` argument that contains variables that
+will be expanded based on the status of the working tree. For example, to
+generate a C header file with a formatted string containing the current
+revision number::
+
+ bzr version-info --custom \
+ --template="#define VERSION_INFO \"Project 1.2.3 (r{revno})\"\n" \
+ > version_info.h
+
+where the ``{revno}`` will be replaced by the revision number of the
+working tree. (If the example above doesn't work on your OS, try
+entering the command all on one line.) For more information on the
+variables that can be used in templates, see `Version Info`_ in the
+Bazaar User Reference.
+
+.. _Version Info: ../user-reference/index.html#version-info
+
+Predefined formats for dumping version information in specific languages
+are currently in development. Please contact us on the mailing list about
+your requirements in this area.
+
+Check clean
+-----------
+
+Most information about the contents of the project can be cheaply
+determined by just reading the revision entry. However, it can be useful
+to know if the working tree was completely up-to-date when it was
+packaged, or if there was a local modification. By supplying either
+``--all`` or ``--check-clean``, ``bzr`` will inspect the working tree, and
+set the ``clean`` flag in ``version_info``, as well as set entries in
+``file_revisions`` as ``modified`` where appropriate.
+
+..
+ vim: tw=74 ft=rst spell spelllang=en_us
diff --git a/doc/en/user-guide/web_browsing.txt b/doc/en/user-guide/web_browsing.txt
new file mode 100644
index 0000000..bb2434a
--- /dev/null
+++ b/doc/en/user-guide/web_browsing.txt
@@ -0,0 +1,15 @@
+Web browsing
+============
+
+Overview
+--------
+
+There are a range of options available for providing a web view of a
+Bazaar repository, the main one being Loggerhead. The homepage of Loggerhead
+can be found at https://launchpad.net/loggerhead.
+
+A list of alternative web viewers including download links can be found on
+http://wiki.bazaar.canonical.com/WebInterface.
+
+Note: If your project is hosted or mirrored on Launchpad,
+Loggerhead code browsing is provided as part of the service.
diff --git a/doc/en/user-guide/working_offline_central.txt b/doc/en/user-guide/working_offline_central.txt
new file mode 100644
index 0000000..2d54326
--- /dev/null
+++ b/doc/en/user-guide/working_offline_central.txt
@@ -0,0 +1,54 @@
+Working offline on a central branch
+===================================
+
+The centralized with local commits workflow
+-------------------------------------------
+
+If you lose your network connection because you are travelling, the central
+server goes down, or you simply want to snapshot changes locally without
+publishing them centrally just yet, this workflow is for you.
+
+.. image:: images/workflows_localcommit.png
+
+Committing locally
+------------------
+
+If you're working in a checkout and need/wish to commit locally only,
+add the ``--local`` option to the ``commit`` command like this::
+
+ bzr commit --local
+
+Being disconnected for long time periods
+----------------------------------------
+
+If you will be or want to be disconnected from the bound branch for
+a while, then remembering to add ``--local`` to every ``commit`` command
+can be annoying. An alternative is to use the ``unbind`` command to
+make the checkout temporarily into a normal branch followed by the
+``bind`` command at some later point in time when you want to
+keep in lockstep again.
+
+Note that the ``bind`` command remembers where you were bound to
+last time this branch was a checkout so it isn't necessary to enter
+the URL of the remote branch when you use ``bind`` after an earlier
+``unbind``.
+
+Merging a series of local commits
+---------------------------------
+
+When you make commits locally independent of ongoing development
+on a central branch, then Bazaar treats these as two lines of
+development next time you ``update``. In this case, ``update``
+does the following:
+
+ * it brings the latest revisions from the bound branch down and
+ makes that the mainline of development within your checkout
+
+ * it moves your local changes since you last updated into a logical
+ parallel branch
+
+ * it merges these together so that your local changes are reported
+ as a pending merge by ``status``.
+
+As always, you will need to run ``commit`` after this to send your
+work to the central branch.
diff --git a/doc/en/user-guide/writing_a_plugin.txt b/doc/en/user-guide/writing_a_plugin.txt
new file mode 100644
index 0000000..0f541b7
--- /dev/null
+++ b/doc/en/user-guide/writing_a_plugin.txt
@@ -0,0 +1,62 @@
+Writing a plugin
+================
+
+Introduction
+------------
+
+Plugins are very similar to bzr core functionality. They can import
+anything in bzrlib. A plugin may simply override standard functionality,
+but most plugins supply new commands.
+
+Creating a new command
+----------------------
+
+To create a command, make a new object that derives from
+``bzrlib.commands.Command``, and name it ``cmd_foo``, where foo is the name of
+your command. If you create a command whose name contains an underscore,
+it will appear in the UI with the underscore turned into a hyphen. For
+example, `cmd_baz_import` will appear as `baz-import`. For examples of how
+to write commands, please see ``builtins.py``.
+
+Once you've created a command you must register the command with
+``bzrlib.commands.register_command(cmd_foo)``. You must register the
+command when your file is imported, otherwise bzr will not see it.
+
+Installing a hook
+-----------------
+
+See `Using hooks`_.
+
+ .. _Using hooks: hooks.txt
+
+
+Specifying a plugin version number
+----------------------------------
+Simply define ``version_info`` to be a tuple defining the current version
+number of your plugin. eg.
+``version_info = (0, 9, 0)``
+``version_info = (0, 9, 0, 'dev', 0)``
+
+Plugin searching rules
+----------------------
+
+Bzr will scan ``~/.bazaar/plugins`` and ``bzrlib/plugins`` for plugins
+by default. You can override this with ``BZR_PLUGIN_PATH``
+(see `User Reference
+<../user-reference/configuration-help.html#bzr-plugin-path>`_ for details).
+
+Plugins may be either modules or packages. If your plugin is a single
+file, you can structure it as a module. If it has multiple files, or if
+you want to distribute it as a bzr branch, you should structure it as a
+package, i.e. a directory with an ``__init__.py`` file.
+
+More information
+----------------
+
+Please feel free to contribute your plugin to BzrTools, if you think it
+would be useful to other people.
+
+See the `Bazaar Developer Guide`_ for details on Bazaar's development
+guidelines and policies.
+
+.. _Bazaar Developer Guide: ../developer-guide/HACKING.html
diff --git a/doc/en/user-guide/zen.txt b/doc/en/user-guide/zen.txt
new file mode 100644
index 0000000..e54f2c1
--- /dev/null
+++ b/doc/en/user-guide/zen.txt
@@ -0,0 +1,216 @@
+Bazaar Zen
+==========
+
+Grokking Bazaar
+---------------
+
+While Bazaar is similar to other VCS tools in many ways, there are
+some important differences that are not necessarily obvious at first
+glance. This section attempts
+to explain some of the things users need to know in order to "grok" Bazaar,
+i.e. to deeply understand it.
+
+Note: It isn't necessary to fully understand this section to use Bazaar.
+You may wish to skim this section now and come back to it at a later time.
+
+Understanding revision numbers
+------------------------------
+
+All revisions in the mainline of a branch have a simple increasing
+integer. (First commit gets 1, 10th commit gets 10, etc.) This makes them
+fairly natural to use when you want to say "grab the 10th revision from my
+branch", or "fixed in revision 3050".
+
+For revisions which have been merged into a branch, a dotted notation is used
+(e.g., 3112.1.5). Dotted revision numbers have three numbers [#]_. The first
+number indicates what mainline revision change is derived from. The second
+number is the branch counter. There can be many branches derived from the
+same revision, so they all get a unique number. The third number is the
+number of revisions since the branch started. For example, 3112.1.5 is the
+first branch from revision 3112, the fifth revision on that branch.
+
+.. [#] Versions prior to bzr 1.2 used a slightly different algorithm.
+ Some nested branches would get extra numbers (such as 1.1.1.1.1)
+ rather than the simpler 3-number system.
+
+Hierarchical history is good
+----------------------------
+
+Imagine a project with multiple developers contributing changes where
+many changes consist of a series of commits. To give a concrete example,
+consider the case where:
+
+ * The tip of the project's trunk is revision 100.
+ * Mary makes 3 changes to deliver feature X.
+ * Bill makes 4 changes to deliver feature Y.
+
+If the developers are working in parallel and using a traditional
+centralized VCS approach, the project history will most likely be linear
+with Mary's changes and Bill's changes interleaved. It might look like this::
+
+ 107: Add documentation for Y
+ 106: Fix bug found in testing Y
+ 105: Fix bug found in testing X
+ 104: Add code for Y
+ 103: Add documentation for X
+ 102: Add code and tests for X
+ 101: Add tests for Y
+ 100: ...
+
+Many teams use this approach because their tools make branching and merging
+difficult. As a consequence, developers update from and commit to the trunk
+frequently, minimizing integration pain by spreading it over every commit.
+If you wish, you can use Bazaar exactly like this. Bazaar does offer other
+ways though that you ought to consider.
+
+An alternative approach encouraged by distributed VCS tools is to create
+feature branches and to integrate those when they are ready. In this case,
+Mary's feature branch would look like this::
+
+ 103: Fix bug found in testing X
+ 102: Add documentation for X
+ 101: Add code and tests for X
+ 100: ...
+
+And Bill's would look like this::
+
+ 104: Add documentation for Y
+ 103: Fix bug found in testing Y
+ 102: Add code for Y
+ 101: Add tests for Y
+ 100: ...
+
+If the features were independent and you wanted to keep linear history,
+the changes could be pushed back into the trunk in batches. (Technically,
+there are several ways of doing that but that's beyond the scope of
+this discussion.) The resulting history might look like this::
+
+ 107: Fix bug found in testing X
+ 106: Add documentation for X
+ 105: Add code and tests for X
+ 104: Add documentation for Y
+ 103: Fix bug found in testing Y
+ 102: Add code for Y
+ 101: Add tests for Y
+ 100: ...
+
+While this takes a bit more effort to achieve, it has some advantages over
+having revisions randomly intermixed. Better still though, branches can
+be merged together forming a non-linear history. The result might look
+like this::
+
+ 102: Merge feature X
+ 100.2.3: Fix bug found in testing X
+ 100.2.2: Add documentation for X
+ 100.2.1: Add code and tests for X
+ 101: Merge feature Y
+ 100.1.4: Add documentation for Y
+ 100.1.3: Fix bug found in testing Y
+ 100.1.2: Add code for Y
+ 100.1.1: Add tests for Y
+ 100: ...
+
+Or more likely this::
+
+ 102: Merge feature X
+ 100.2.3: Fix bug
+ 100.2.2: Add documentation
+ 100.2.1: Add code and tests
+ 101: Merge feature Y
+ 100.1.4: Add documentation
+ 100.1.3: Fix bug found in testing
+ 100.1.2: Add code
+ 100.1.1: Add tests
+ 100: ...
+
+This is considered good for many reasons:
+
+ * It makes it easier to understand the history of a project.
+ Related changes are clustered together and clearly partitioned.
+
+ * You can easily collapse history to see just the commits on the mainline
+ of a branch. When viewing the trunk history like this, you only see
+ high level commits (instead of a large number of commits uninteresting
+ at this level).
+
+ * If required, it makes backing out a feature much easier.
+
+ * Continuous integration tools can be used to ensure that
+ all tests still pass before committing a merge to the mainline.
+ (In many cases, it isn't appropriate to trigger CI tools after
+ every single commit as some tests will fail during development.
+ In fact, adding the tests first - TDD style - will guarantee it!)
+
+In summary, the important points are:
+
+ *Organize your work using branches.*
+
+ *Integrate changes using merge.*
+
+ *Ordered revision numbers and hierarchy make history easier to follow.*
+
+
+Each branch has its own view of history
+---------------------------------------
+
+As explained above, Bazaar makes the distinction between:
+
+ * mainline revisions, i.e. ones you committed in your branch, and
+
+ * merged revisions, i.e. ones added as ancestors by committing a merge.
+
+Each branch effectively has its own view of history, i.e. different
+branches can give the same revision a different "local" revision number.
+Mainline revisions always get allocated single number revision numbers
+while merged revisions always get allocated dotted revision numbers.
+
+To extend the example above, here's what the revision history of
+Mary's branch would look like had she decided to merge the project
+trunk into her branch after completing her changes::
+
+ 104: Merge mainline
+ 100.2.1: Merge feature Y
+ 100.1.4: Add documentation
+ 100.1.3: Fix bug found in testing
+ 100.1.2: Add code
+ 100.1.1: Add tests
+ 103: Fix bug found in testing X
+ 102: Add documentation for X
+ 101: Add code and tests for X
+ 100: ...
+
+Once again, it's easy for Mary to look at just *her* top level of history
+to see the steps she has taken to develop this change. In this context,
+merging the trunk (and resolving any conflicts caused by doing that) is
+just one step as far as the history of this branch is concerned.
+
+It's important to remember that Bazaar is not changing history here, nor
+is it changing the global revision identifiers. You can always use the
+latter if you really want to. In fact, you can use the branch specific
+revision numbers when communicating *as long as* you provide the branch
+URL as context. (In many Bazaar projects, developers imply the central
+trunk branch if they exchange a revision number without a branch URL.)
+
+Merges do not change revision numbers in a branch, though they do
+allocate local revision numbers to newly merged revisions. The only time
+Bazaar will change revision numbers in a branch is when you explicitly
+ask it to mirror another branch.
+
+Note: Revisions are numbered in a stable way: if two branches have
+the same revision in their mainline, all revisions in the ancestry of that
+revision will have the same revision numbers. For example, if Alice and Bob's
+branches agree on revision 10, they will agree on all revisions before
+that.
+
+Summary
+-------
+
+In general, if you follow the advice given earlier - organise
+your work in branches and use merge to collaborate - you'll find Bazaar
+generally does what you expect.
+
+In coming chapters, we examine various ways of using Bazaar beginning with
+the simplest: using Bazaar for personal projects.
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/en/user-reference/readme.txt b/doc/en/user-reference/readme.txt
new file mode 100644
index 0000000..ae1337d
--- /dev/null
+++ b/doc/en/user-reference/readme.txt
@@ -0,0 +1,8 @@
+Note: The contents of the User Reference are fully generated from
+Bazaar's online help topics. If you wish to edit this material,
+most of it can be found under bzrlib/help_topics/. In some cases
+though, the material is built by probing various internal
+registries, e.g. the set of available file formats. If you're
+not sure where to find the source content you're looking for,
+please contact the developers on the mailing list or IRC.
+See http://wiki.bazaar.canonical.com/BzrSupport for contact details.
diff --git a/doc/en/whats-new/template.txt b/doc/en/whats-new/template.txt
new file mode 100644
index 0000000..8bae435
--- /dev/null
+++ b/doc/en/whats-new/template.txt
@@ -0,0 +1,26 @@
+*************************
+What's New in Bazaar x.y?
+*************************
+
+Bazaar x.y is still under development, and will be released in Month Year.
+This document accumulates a high level summary of what's changed. See the
+:doc:`../release-notes/index` for a full list.
+
+<topics of interest here>
+
+Further information
+*******************
+
+For more detailed information on the changes made, see the the
+:doc:`../release-notes/index` for:
+
+* the interim bzr `milestones <https://launchpad.net/bzr/x.y>`_
+* the plugins you use.
+
+For a summary of changes made in earlier releases, see:
+
+* :doc:`whats-new-in-2.1`
+* :doc:`whats-new-in-2.2`
+* :doc:`whats-new-in-2.3`
+<intermediate series here>
+* :doc:`whats-new-in-x.(y-1)`
diff --git a/doc/en/whats-new/whats-new-in-2.1.txt b/doc/en/whats-new/whats-new-in-2.1.txt
new file mode 100644
index 0000000..c9c5138
--- /dev/null
+++ b/doc/en/whats-new/whats-new-in-2.1.txt
@@ -0,0 +1,212 @@
+What's New in Bazaar 2.1?
+=========================
+
+This document outlines the major improvements in Bazaar 2.1
+vs Bazaar 2.0. As well as summarizing improvements made to
+the core product, it highlights enhancements within the broader
+Bazaar world of potential interest to those upgrading.
+
+Bazaar 2.1.0 marks the start of our second long-term-stable series.
+This series will be supported with bug fixes for the next 12 months.
+All users are encouraged to upgrade from the 2.0.x stable series.
+
+
+Better efficiency
+-----------------
+
+Many operations now consume less memory. Several operations are
+also faster including branching, logging merged revisions and
+upgrading from pre-2a to 2a format.
+
+
+New command options
+-------------------
+
+Several commands have new options. These include:
+
+=========== ============== ======================================
+Command Option Description
+=========== ============== ======================================
+branch bind Bind to the source location
+commit commit-time Give an explicit commit timestamp
+switch revision Switch to a particular revision
+unshelve keep Apply changes but don't delete them
+unshelve preview Show the diff that would result from
+ unshelving
+update revision Update to a particular revision
+=========== ============== ======================================
+
+Other command improvements include:
+
+* A :doc:`../user-reference/shelve-help` editor can be defined to provide shelf functionality at
+ a granularity finer than per-patch hunk.
+
+* :doc:`../user-reference/send-help` send now supports the OS X Mail application.
+
+See the help for the commands above for further details.
+
+
+Per-file merge hooks
+--------------------
+
+Hooks can now be defined for smart merging of selected file types.
+This enables easier merging of ChangeLogs, Release Notes and other
+file that frequently conflict.
+
+
+DWIM revision identifiers
+-------------------------
+
+Revision identifiers can now be given in a *Do-What-I-Mean* style.
+For example, you can now just give a tag (instead of saying ``tag:xxx``)
+or just say ``today`` (instead of saying ``date:today``). Prefixes
+are now only required if the revision spec could be ambiguous.
+
+Launchpad compatibility
+-----------------------
+
+Launchpad has `announced
+<http://blog.launchpad.net/general/edge-is-deprecated>`_ that the
+``edge.launchpad.net`` instance is deprecated and may be shut down in the
+future . Bazaar has therefore been updated in this release to talk to the main
+(``launchpad.net``) servers, rather than the ``edge`` ones (the same code is
+running on both servers during the interim).
+
+
+New ignore patterns
+-------------------
+
+Patterns prefixed with ``!`` are exceptions to ignore patterns and
+take precedence over regular ignores. Such exceptions are used to
+specify files that should be versioned which would otherwise be
+ignored. Patterns prefixed with ``!!`` act as regular ignore patterns,
+but have highest precedence, even over the ``!`` exception patterns.
+
+
+Smart server home directory support
+-----------------------------------
+
+``bzr+ssh`` and ``bzr`` paths can now be relative to home directories
+specified in the URL. Paths starting with a path segment of ``~`` are
+relative to the home directory of the user running the server, and paths
+starting with ``~user`` are relative to the home directory of the named
+user. For example, for a user "bob" with a home directory of
+``/home/bob``, these URLs are all equivalent:
+
+* ``bzr+ssh://bob@host/~/repo``
+* ``bzr+ssh://bob@host/~bob/repo``
+* ``bzr+ssh://bob@host/home/bob/repo``
+
+If ``bzr serve`` was invoked with a ``--directory`` argument, then no
+home directories outside that directory will be accessible via this
+method.
+
+This is a feature of ``bzr serve``, so pre-2.1 clients will
+automatically benefit from this feature when ``bzr`` on the server is
+upgraded.
+
+
+Generalized glob support on Windows
+-----------------------------------
+
+On Windows, glob expansion is now handled in a universal way across
+all commands. In previous versions, it was explicitly handed by just
+a few commands, e.g. ``add``. A side effect of this change is that
+patterns now need to be quoted when passed to the ``ignore`` command,
+e.g. ``bzr ignore *.foo`` now needs to be given as ``bzr ignore "*.foo"``.
+
+
+Improved Git and Mercurial interoperability
+-------------------------------------------
+
+Many improvements have been made to the git_ and hg_ plugins.
+With these plugins installed, most Git and Mercurial repositories
+can now be read by standard Bazaar clients. Changes can also
+be written back via the dpush command.
+
+.. _git: http://doc.bazaar.canonical.com/plugins/en/git-plugin.html
+.. _hg: http://doc.bazaar.canonical.com/plugins/en/hg-plugin.html
+
+
+Metaprojects
+------------
+
+New plugins are available for constructing larger projects
+from smaller ones. These include:
+
+* builder_ - construction of a branch using recipes
+* externals_ - Subversion-style external branches
+
+.. note::
+
+ The builder plugin has been designed to complement the builddeb_
+ plugin to streamline Debian source package management. It may also
+ be useful for building test images for a QA team or disk images
+ for installers, say.
+
+.. _builder: http://doc.bazaar.canonical.com/plugins/en/builder-plugin.html
+.. _externals: http://doc.bazaar.canonical.com/plugins/en/externals-plugin.html
+.. _builddeb: http://doc.bazaar.canonical.com/plugins/en/builddeb-plugin.html
+
+
+Colocated branch workspaces
+---------------------------
+
+A colocated workspace is one where a single working tree is used
+across one or more branches managed at that same location. This
+is now supported by the new colo_ plugin and by Bazaar Explorer.
+
+.. _colo: http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
+
+
+Better documentation
+--------------------
+
+A :doc:`../admin-guide/index` covering topics such as setting up servers,
+security, backups and email integration has been added.
+
+A large number of documentation bugs have been fixed, clarifying
+numerous issues and filling in some missing holes.
+
+The :doc:`../user-reference/index`
+has been organized into topics making it easier to
+navigate through and print selected sections of.
+
+To assist users migrating from other tools, a
+`Survival Guide <http://doc.bazaar.canonical.com/migration/en/survival/index.html>`_
+has been published explaining Bazaar to users of other tools in terms they
+already know. Sections are provided for existing users of
+CVS, Subversion, ClearCase, Perforce, Visual SourceSafe, Git, Mercurial,
+Darcs and Monotone.
+
+Selected documents have also been translated to Japanese.
+
+
+Enhanced GUI clients
+--------------------
+
+Numerous enhancements have been made to most of our GUIs including
+Bazaar Explorer, TortoiseBZR and the QBzr-Eclipse add-on. These
+applications all build on top of improvements made to QBzr. Bzr-gtk
+has also been improved.
+
+Bazaar Explorer has over a dozen new features including smart toolbars,
+support for all bzr commands (including those in plugins),
+a better working tree browser and a submit delta report showing the
+cumulative effect of a series of commits.
+See `What's New in Bazaar Explorer 1.0?
+<http://doc.bazaar.canonical.com/explorer/en/whats-new/whats-new-in-1.0.html>`_
+for more information.
+
+
+Further information
+-------------------
+
+For more detailed information on the changes made, be sure to check
+the :doc:`../release-notes/index` for:
+
+* the interim bzr `milestones <https://launchpad.net/bzr/2.1>`_
+* the plugins you use.
+
+Enjoy,
+The Bazaar Development Team
diff --git a/doc/en/whats-new/whats-new-in-2.2.txt b/doc/en/whats-new/whats-new-in-2.2.txt
new file mode 100644
index 0000000..483cb22
--- /dev/null
+++ b/doc/en/whats-new/whats-new-in-2.2.txt
@@ -0,0 +1,314 @@
+*************************
+What's New in Bazaar 2.2?
+*************************
+
+Bazaar 2.2.0, released on the 6th of August 2010, marks the start of
+another long-term-stable series. From here, we will only make bugfix
+releases on the 2.2 series (2.2.1, etc), while 2.3 will become our new
+development series. The 2.0 and 2.1 series will also continue to get
+bugfixes. (Currently 2.0 is planned to be supported for another 6 months.)
+
+The main changes in 2.2 are: **better local and network performance**,
+**reduced memory usage**, and several user-interface improvements.
+
+Users are encouraged to upgrade from the other stable series. This
+document outlines the improvements in Bazaar 2.2 vs Bazaar 2.1. As well as
+summarizing improvements made to the core product, it highlights
+enhancements within the broader Bazaar world of potential interest to
+those upgrading.
+
+Bazaar 2.2.0 includes all the fixes from 2.1.2 and 2.0.6.
+
+Over 120 bugs have been fixed in total. See the
+:doc:`../release-notes/index` for a full list.
+
+Bazaar 2.2.1 includes all the fixes from 2.1.3 and 2.0.6 (that
+weren't included in 2.2.0).
+
+See the :doc:`../release-notes/index` for details.
+
+Bazaar 2.2.2 focused on fixes to improve our Ubuntu release workflow (which
+should also help all other distributions).
+
+See the :doc:`../release-notes/index` for details.
+
+Bazaar 2.2.3 focused on fixes related to interactions with the launchpad
+server and python-2.7 compatibility.
+
+Bazaar 2.2.4 fixed a regression for some interactions with the launchpad
+server.
+
+Bazaar 2.2.5 fixed a regression in some rare conflict resolutions and warns
+when branching an out-of-date ubuntu packaging branch.
+
+See the :doc:`../release-notes/index` for details.
+
+Bazaar 2.2 is fully compatible both locally and on the network with 2.0
+and 2.1, and can read and write repositories generated by all previous
+versions.
+
+
+Behaviour changes
+*****************
+
+There are some compatibility changes in this release.
+
+* For commandline users we no longer guess user identity for ``bzr
+ commit``: users must specify their identity using ``bzr whoami`` (you
+ don't need to specify your identity for readonly operations).
+ This avoids problems where the previous guessed default caused commits
+ be recorded as coming from, for example ``<sam@localhost>``.
+
+Improved conflict handling
+**************************
+
+Tree-shape conflicts can be resolved by providing ``--take-this`` and
+``--take-other`` to the ``bzr resolve`` command. Just marking the conflict
+as resolved is still accessible via the ``--done`` default action.
+
+Local performance
+*****************
+
+* ``bzr init`` does not recursively scan directory contents anymore
+ leading to faster init for directories with existing content.
+ (Martin [gz], Parth Malwankar, #501307)
+
+* Less code is loaded at startup, so there's less overhead on running all
+ bzr commands.
+ (Andrew Bennetts, Martin Pool)
+
+* Reduce peak memory by one copy of compressed text.
+ (John Arbash Meinel, #566940)
+
+* Avoid repeated locking of local objects in ``diff``, ``missing``, and
+ ``pull``, so those options are faster.
+ (Andrew Bennetts)
+
+Network performance
+*******************
+
+* Bazaar now reads data from SSH connections more efficiently on platforms
+ that provide the ``socketpair`` function, and when using paramiko.
+ (Andrew Bennetts, #590637)
+
+* Index lookups in pack repositories search recently hit pack files
+ first. In repositories with many pack files this can greatly reduce the
+ number of files accessed, the number of bytes read, and the number of
+ read calls. An incremental pull via plain HTTP takes half the time and
+ bytes for a moderately large repository. (Andrew Bennetts)
+
+* Index lookups only re-order the indexes when the hit files aren't
+ already first. Reduces the cost of reordering
+ (John Arbash Meinel, #562429)
+
+
+Command improvements
+********************
+
+* Added ``bzr remove-branch`` command that can remove a local or remote
+ branch. (Jelmer Vernooij, #276295)
+
+* ``bzr export`` now takes an optional argument ``--per-file-timestamps``
+ to set file mtimes to the last timestamp of the last revision in which
+ they were changed rather than the current time. (Jelmer Vernooij)
+
+* Tag names can now be determined automatically by ``automatic_tag_name``
+ hooks on ``Branch`` if they are not specified on the command line.
+ (Jelmer Vernooij)
+
+* Tree-shape conflicts can be resolved by providing ``--take-this`` and
+ ``--take-other`` to the ``bzr resolve`` command. Just marking the conflict
+ as resolved is still accessible via the ``--done`` default action.
+ (Vincent Ladeuil)
+
+* The ``--directory`` option is supported for a number of additional
+ commands: added, annotate, bind, cat, cat-revision, clean-tree,
+ conflicts, deleted, export, ignore, ignored, lookup-revision, ls,
+ merge-directive, missing, modified, nick, re-sign, resolve, shelve,
+ switch, unbind, unknowns, unshelve, whoami.
+ (Martin von Gagern, #527878)
+
+* ``bzr commit`` accepts ``-p`` (for "patch") as a shorter name for
+ ``--show-diff``.
+ (Parth Malwankar, #571467)
+
+* ``bzr ignore`` now supports a ``--default-rules`` option that displays
+ the default ignore rules used by bzr. The flag ``--old-default-rules``
+ is no longer supported by ``ignore``.
+ (Parth Malwankar, #538703)
+
+* ``bzr pack`` now supports a ``--clean-obsolete-packs`` option that
+ can save disk space by deleting obsolete pack files created during the
+ pack operation.
+ (Parth Malwankar, #304320)
+
+* New command line option ``--authors`` to ``bzr log`` allows users to
+ select which of the apparent authors and committer should be
+ included in the log. Defaults depend on format. (Martin von Gagern, #513322)
+
+* The bash_completion plugin from the bzr-bash-completion project has
+ been merged into the tree. It provides a bash-completion command and
+ replaces the outdated ``contrib/bash/bzr`` script with a version
+ using the plugin. (Martin von Gagern, #560030)
+
+* A new transport based on GIO (the gnome i/o library) provides access to
+ samba shares, webdav using gio+smb and gio+dav. It is also possible to
+ use gio for some already existing transport methods as gio+file,
+ gio+sftp, gio+ftp.
+ (Mattias Eriksson)
+
+
+Controlling plugins
+*******************
+
+* Plugins can be disabled by defining ``BZR_DISABLE_PLUGINS`` as
+ a list of plugin names separated by ':' (';' on windows).
+ (Vincent Ladeuil, #411413)
+
+* Plugins can be loaded from arbitrary locations by defining
+ ``BZR_PLUGINS_AT`` as a list of ``name@path`` separated by ':' (';' on
+ Microsoft
+ Windows). This takes precedence over ``BZR_PLUGIN_PATH`` for the
+ specified plugins, and is expected to be most useful for plugin
+ developers.
+ (Vincent Ladeuil, #82693)
+
+
+Apport crash reporting
+**********************
+
+* If the Apport crash-reporting tool is available, bzr crashes are now
+ stored into the ``/var/crash`` apport spool directory, and the user is
+ invited to report them to the developers from there, either
+ automatically or by running ``apport-bug``. No information is sent
+ without specific permission from the user. (Martin Pool, #515052)
+
+
+Improved Launchpad integration
+******************************
+
+* Merges can be proposed on Launchpad with the new ``lp-propose-merge``
+ command.
+
+
+Better documentation
+********************
+
+* ``bzr help patterns`` now explains case insensitive patterns and
+ points to Python regular expression documentation.
+ (Parth Malwankar, #594386)
+
+* Numerous improvements have been made to the developer documentation.
+
+
+Changes to plugins
+******************
+
+
+bzr grep
+========
+
+The `grep plugin <https://launchpad.net/bzr-grep>`_ has developed well
+during the bzr 2.2 cycle. bzr grep can search the versioned files in the
+working tree, or in one or a series of revisions, or it can search through
+only the changes in a revision range.
+
+qbzr
+====
+
+`qbzr <https://launchpad.net/qbzr>`_, a cross-platform graphical interface
+to Bazaar, gained many features and fixes in its 0.19 release, including:
+
+* qannotate has new look and feel; with new features: find text and goto
+ to line.
+
+* Improved performance of qlog, and treewidget-based dialogs (qcommit,
+ qadd, qrevert etc.)
+
+* qpush, qmerge, etc.: when there are uncommitted changes in the working
+ tree, user has the option to commit, or revert.
+
+* qcommit: user can update bound branch/checkout if it is not up to date.
+
+* Better support of Mac OS X: dialog windows no more start in background.
+
+* qlog: Context menu actions for tag and revert will now show a branch
+ menu if more than one branch is open.
+
+* qlog: more context menu actions for update, cherry-pick, and reverse
+ cherry-pick.
+
+* Language of GUI can be set in DEFAULT section of bazaar.conf
+ as ``language = code``. Language codes are the same
+ as for ``LANG`` environment variable.
+ Environment variable ``LANGUAGE`` still preferred over settings
+ in bazaar.conf.
+
+
+Platform-specific changes
+*************************
+
+Microsoft Windows
+=================
+
+* There's a new py2exe windows program ``bzrw.exe``, which allows for starting a Bazaar GUI with out have a console open in the background. (Gary van der Merwe, #433781`)
+
+* The all-in-one Windows installer will now be built with docstrings stripped
+ from the library zip, reducing the size and slightly improving cold startup
+ time. Bundled plugins are unchanged for the moment, but if adding other new
+ plugins to an all-in-one installation, ensure they are compiled and
+ installed with -O1 or help may not work. (Martin [gz])
+
+* Parsing of command lines, for example in ``diff --using``, no longer
+ treats backslash as an escape character on Windows. (Gordon Tyler,
+ #392248)
+
+
+API changes
+***********
+
+* BzrError subclasses no longer support the name "message" to be used
+ as an argument for __init__ or in _fmt format specification as this
+ breaks in some Python versions. errors.LockError.__init__ argument
+ is now named "msg" instead of earlier "message".
+ (Parth Malwankar, #603461)
+
+* The old ``bzr selftest --benchmark`` option has been removed.
+ <https://launchpad.net/bzr-usertest> is an actively-maintained
+ macrobenchmark suite.
+ (Martin Pool)
+
+* bzrlib library users now need to call ``__enter__`` and ``__exit__`` on
+ the result of ``bzrlib.initialize``. This change was made when fixing
+ the bad habit recent bzr versions have had of leaving progress bars
+ behind on the screen. That required calling another function before
+ exiting the program, and it made sense to provide a full context
+ manager at the same time. (Robert Collins)
+
+* The ``bzr`` front end now requires a ``bzrlib.ui.ui_factory`` which is a
+ context manager in the Python 2.5 and above sense. The bzrlib base class
+ is such a manager, but third party UI factories which do not derive from
+ ``bzrlib.ui.UIFactory`` will be incompatible with the command line front
+ end.
+
+* URLs like ``foo:bar/baz`` are now always parsed as a URL with scheme "foo"
+ and path "bar/baz", even if bzr does not recognize "foo" as a known URL
+ scheme. Previously these URLs would be treated as local paths.
+ (Gordon Tyler)
+
+
+Further information
+*******************
+
+For more detailed information on the changes made, see the
+the :doc:`../release-notes/index` for:
+
+* the interim bzr `milestones <https://launchpad.net/bzr/2.2>`_
+* the plugins you use.
+
+For a summary of changes made in earlier releases, see:
+
+* :doc:`whats-new-in-2.1`
+
+
+.. vim: ft=rst
diff --git a/doc/en/whats-new/whats-new-in-2.3.txt b/doc/en/whats-new/whats-new-in-2.3.txt
new file mode 100644
index 0000000..ecd06f3
--- /dev/null
+++ b/doc/en/whats-new/whats-new-in-2.3.txt
@@ -0,0 +1,205 @@
+*************************
+What's New in Bazaar 2.3?
+*************************
+
+Bazaar 2.3 has been released on the 3rd of February 2011 and marks the start
+of another long-term-stable series. From here, we will only make bugfix
+releases on the 2.3 series (2.3.1, etc), while 2.4 will become our new
+development series. The 2.1 and 2.2 series will also continue to get
+bugfixes. (Currently 2.0 is planned to be EOLed circa September 2011.)
+
+This document accumulates a high level summary of what's changed.
+See the
+:doc:`../release-notes/index` for a full list.
+
+Users are encouraged to upgrade from the other stable series. This document
+outlines the improvements in Bazaar 2.3 vs Bazaar 2.2. As well as summarizing
+improvements made to the core product, it highlights enhancements within the
+broader Bazaar world of potential interest to those upgrading.
+
+Bazaar 2.3.1 includes all the fixes in the un-released 2.0.7, 2.1.4 and 2.2.5
+versions that weren't included in 2.3.0 and fixes some bugs on its own.
+
+Bazaar 2.3.2 is a bugfix release that was never released.
+
+Bazaar 2.3.3 is a bugfix release including the fixes in 2.3.2 and
+fixing the test helpers deprecated by python-2.7.
+
+Bazaar 2.3.4 is a bugfix release.
+
+See the :doc:`../release-notes/index` for details.
+
+Bazaar 2.3 is fully compatible both locally and on the network with 2.0, 2.1,
+and 2.2. It can read and write repositories generated by all previous
+versions.
+
+Changed Behaviour
+*****************
+
+* Committing a new revision in a stacked branch is now supported, as long as
+ you are using the current repository format (2a). It will preserve the
+ stacking invariants, etc, so that fetching after commit is guaranteed to
+ work. (John Arbash Meinel, #375013)
+
+* Support for some old development formats have been removed:
+ ``development-rich-root``, ``development6-rich-root``, and
+ ``development7-rich-root``. These formats were always labelled experimental
+ and not used unless the user specifically asked for them. If you have
+ repositories using these old formats you should upgrade them to ``2a`` using
+ Bazaar 2.2. (Andrew Bennetts)
+
+* The default ``ignore`` file created by Bazaar will contain ``__pycache__``,
+ which is the name of the directory that will be used by Python to store
+ bytecode files.
+ (Andrea Corbellini, #626687)
+
+* The default sort order for the ``bzr tags`` command now uses a natural sort
+ where numeric substrings are sorted numerically. The previous default was
+ "asciibetical" where tags were sorted by the characters they contained. To
+ get the old behavior, one can use ``bzr tags --sort=alpha``.
+ (Neil Martinsen-Burrell, #640760)
+
+* On platforms other than Windows and Mac OS X, Bazaar will use configuration
+ files that live in $XDG_CONFIG_HOME/bazaar if that directory exists. This
+ allows interested individuals to conform to the XDG Base Directory
+ specification. The plugin location has not changed and is still
+ ~/.bazaar/plugins. To use a different directory for plugins, use the
+ environment variable BZR_PLUGIN_PATH. (Neil Martinsen-Burrell, #195397)
+
+* ``bzr upgrade`` now operates recursively when run on a shared
+ repository, automatically upgrading the branches within it, and has
+ grown additional options for showing what it will do and cleaning up
+ after itself. (Ian Clatworthy, Matthew Fuller, #89830, #374734, #422450)
+
+Launchpad integration
+*********************
+
+* The ``lp:`` prefix will now use your known username (from
+ ``bzr launchpad-login``) to expand ``~`` to your username. For example:
+ ``bzr launchpad-login user && bzr push lp:~/project/branch`` will now
+ push to ``lp:~user/project/branch``. (John Arbash Meinel)
+
+* Launchpad has announced that the ``edge.launchpad.net`` instance is
+ deprecated and may be shut down in the future
+ <http://blog.launchpad.net/general/edge-is-deprecated>. Bazaar has therefore
+ been updated in this release to talk to the main (``launchpad.net``) servers,
+ rather than the ``edge`` ones.
+
+Performance improvements
+************************
+
+* ``bzr revert`` and ``bzr status`` are up to 15% faster on large trees
+ with many changes by not repeatedly building a list of all file-ids.
+ (Andrew Bennetts)
+
+* ``bzr send`` uses less memory.
+ (John Arbash Meinel, #614576)
+
+* Fetches involving stacked branches and branches with tags now do slightly less
+ I/O, and so does branching from an existing branch. This also improves the
+ network performance of these operations. (Andrew Bennetts)
+
+* Inventory entries now consume less memory (on 32-bit Ubuntu file entries
+ have dropped from 68 bytes to 40, and directory entries from 120 bytes
+ to 48). This affects most operations, and depending on the size of the
+ tree may substantially improve the speed of operations like ``bzr
+ commit``. (Andrew Bennetts)
+
+* Lower memory consumption when reading many chk index pages. Helpful for
+ things like ``bzr co`` or ``bzr ls -R`` on large trees.
+ (John Arbash Meinel)
+
+* When building new working trees, default to reading from the repository
+ rather than the source tree unless explicitly requested. (via
+ ``--files-from`` and ``--hardlink`` for ``bzr branch`` and
+ ``bzr checkout``. Generally, 2a format repositories extract
+ content faster than seeking and reading content from another tree,
+ especially in cold-cache situations. (John Arbash Meinel, #607298)
+
+New revision specifiers
+***********************
+
+* The ``mainline`` revision specifier has been added. It takes another revision
+ spec as its input, and selects the revision which merged that revision into
+ the mainline.
+
+ For example, ``bzr log -vp -r mainline:1.2.3`` will show the log of the
+ revision that merged revision 1.2.3 into mainline, along with its status
+ output and diff. (Aaron Bentley)
+
+* The ``annotate`` revision specifier has been added. It takes a path and a
+ line as its input (in the form ``path:line``), and selects the revision which
+ introduced that line of that file.
+
+ For example: ``bzr log -vp -r annotate:bzrlib/transform.py:500`` will select
+ the revision that introduced line 500 of transform.py, and display its log,
+ status output and diff.
+
+ It can be combined with ``mainline`` to select the revision that landed this
+ line into trunk, like so:
+ ``bzr log -vp -r mainline:annotate:bzrlib/transform.py:500``
+ (Aaron Bentley)
+
+Testing/Bug reporting
+*********************
+
+* Shell-like scripts can now be run directly from the command line without
+ writing a python test. This should help users adding reproducing recipes
+ to bug reports. (Vincent Ladeuil)
+
+
+Improved conflict handling
+**************************
+
+* ``pull``, ``merge`` or ``switch`` can lead to conflicts when deleting a
+ versioned directory contains unversioned files. The cause of the conflict
+ is that deleting the directory will orphan the unversioned files so the
+ user needs to instruct ``bzr`` what do to do about these orpahns. This is
+ controlled by setting the ``bzr.transform.orphan_policy`` configuration
+ variable with a value of ``move``. In this case the unversioned files are
+ moved to a ``bzr-orphans`` directory at the root of the working tree. The
+ default behaviour is specified (if needed) by setting the variable to
+ ``conflict``. (Vincent Ladeuil, #323111)
+
+* ``bzr resolve --take-this`` and ``bzr resolve --take-other`` can now be
+ used for text conflicts. This will ignore the differences that were merged
+ cleanly and replace the file with its content in the current branch
+ (``--take-this``) or with its content in the merged branch
+ (``--take-other``). (Vincent Ladeuil, #638451)
+
+* ``bzr resolve`` now provides more feedback about the conflicts just
+ resolved and the remaining ones. (Vincent Ladeuil)
+
+Documentation
+*************
+
+* A beta version of the documentation is now available in GNU TexInfo
+ format, used by emacs and the standalone ``info`` reader.
+ (Vincent Ladeuil, #219334)
+
+Configuration
+*************
+
+``bzr`` can be configured via environment variables, command-line options
+and configurations files. We've started working on unifying this and give
+access to more options. The first step is a new ``bzr config`` command that
+can be used to display the active configuration options in the current
+working tree or branch as well as the ability to set or remove an
+option. Scripts can also use it to get only the value for a given option.
+
+Further information
+*******************
+
+For more detailed information on the changes made, see the
+the :doc:`../release-notes/index` for:
+
+* the interim bzr `milestones <https://launchpad.net/bzr/2.3>`_
+* the plugins you use.
+
+For a summary of changes made in earlier releases, see:
+
+* :doc:`whats-new-in-2.1`
+* :doc:`whats-new-in-2.2`
+
+
+.. vim: ft=rst
diff --git a/doc/en/whats-new/whats-new-in-2.4.txt b/doc/en/whats-new/whats-new-in-2.4.txt
new file mode 100644
index 0000000..46c0c91
--- /dev/null
+++ b/doc/en/whats-new/whats-new-in-2.4.txt
@@ -0,0 +1,163 @@
+**********************************
+What's New in Bazaar 2.4 (Oronsay)
+**********************************
+
+Bazaar 2.4 has been released on the 8th of August 2011 and marks the start
+of a new long-term-stable series. From here, we will only make bugfix
+releases on the 2.4 series (2.4.1, etc, and support it until February 2013),
+while 2.5 will become our new development series.
+
+This document accumulates a high level summary of what's changed. See the
+:doc:`../release-notes/index` for a full list.
+
+Users are encouraged to upgrade from the other stable series. This
+document outlines the improvements in Bazaar 2.4 vs Bazaar 2.3. As well as
+summarizing improvements made to the core product, it highlights
+enhancements within the broader Bazaar world of potential interest to
+those upgrading.
+
+Bazaar 2.4.0 is fully compatible both locally and on the network with 2.0,
+2.1, 2.2 and 2.3, and can read and write repositories generated by all
+previous versions.
+
+Bazaar 2.4.1 includes all the fixes in the un-released 2.0.7, 2.1.5, 2.2.6
+and 2.3.5 versions that weren't included in 2.4.0 and fixes some bugs on its
+own.
+
+Bazaar 2.4.2 includes all the fixes in the un-released 2.0.7, 2.1.5, 2.2.6
+and 2.3.5 versions that weren't included in 2.4.1 and fixes some bugs on its
+own.
+
+
+Dropping Python2.4 and Python2.5 support
+****************************************
+
+Bazaar 2.4.0 is the first version of bzr to drop support for python
+versions before 2.6. The 2.3 series will still be maintained in bugfix
+mode for people who need older versions of python. You can also use
+Launchpad to nominate fixes for 2.3. We can't fix everything, but that can
+help guide us to what people are running into. Upgrading to python2.6
+allows us to clean up the syntax in our files, and makes it easier to work
+on python3 compatibility.
+
+External merge tools
+********************
+
+External merge tool configuration has been added to ``bzr`` core. The name
+and commandline of one or more external merge tools can be defined in
+bazaar.conf. See the help topic ``configuration`` for more details.
+
+Tagged revisions are copied
+***************************
+
+When tags are copied from a branch, the associated revisions are now copied
+too if the config entry ``branch.fetch_tags`` is set to True. Operations
+like branching, merging or pulling will still always copy new tags visible
+in ``bzr tags``. When the config is set, it will now also copy the
+revisions and their ancestry. This way tagged revisions will always be
+present, so that operations like ``bzr log -r tag:foo`` will always work.
+
+Deprecated command synonyms
+***************************
+
+Two built-in synonyms for ``bzr branch`` have been deprecated: ``clone`` and
+``get``.
+
+Command options
+***************
+
+* The ``bzr log`` and ``bzr missing`` commands now accept ``-S`` as a
+ shorthand for ``--short``.
+
+Configuration files
+*******************
+
+Option values can now refer to other options in the same configuration file
+by enclosing them in curly brackets (``{option}``). This is an opt-in
+feature controlled by the ``bzr.config.expand`` option that should be
+declared in ``bazaar.conf`` and no other file.
+
+Changelog merge plugin
+**********************
+
+The ``changelog_merge`` plugin has been added. It provides a merge hook
+to automate merging of changes to ``ChangeLog`` files in GNU's change log
+format. Refer to ``bzr help changelog_merge`` for documentation on how to
+enable it and what it can do.
+
+Faster operations on Large Trees
+********************************
+
+Many bzr commands used to run into pathological behavior on large trees
+(>10k files), reading the inventory data in random order causing cache
+thrashing (the fix was backported to bzr-2.3.2). We also updated several
+code paths that were updating the WT state using an O(tree) operation to
+one that was an O(changes) operation. A possibly incomplete list is as
+follows for running commands on a 70k file tree::
+
+ bzr-2.3.1 bzr-2.3.2 bzr-2.4 action
+ 3m39s 1m08s 1m03s bzr co --lightweight
+ 38s 8s 2s bzr revert (in a clean tree)
+ 4m47s 3m56s 15s bzr merge
+ 4m45s 20s 3s bzr pull
+ 4m58s 3m00s 2s bzr up
+ 9m33s 21s 19s bzr uncommit (including a merge)
+ 4m44s 17s 2s bzr uncommit (simple commit)
+
+This is a smaller table of times for the Launchpad tree (~8k items)::
+
+ bzr-2.3.1 bzr-2.4 action
+ 5.3s 5.2s bzr co --lightweight
+ 0.9s 0.3s bzr revert
+ 1.4s 0.4s bzr pull
+ 3.9s 3.7s bzr uncommit (with merge)
+ 0.9s 0.3s bzr uncommit (without merge)
+
+Faster stacked branches
+***********************
+
+Creating a stacked branch from a smart server with ``bzr branch
+--stacked`` is a bit faster now. For small branches it does 20% fewer
+network roundtrips. Other operations where a local branch is stacked on a
+branch hosted on a smart server will also benefit.
+
+More export control
+*******************
+
+When exporting a tree, you may now use get_export_generator() to
+do an operation after each file is exported.
+
+Testing
+*******
+
+The ``selftest --exclude`` option can now be specified multiple times and
+the tests that match any of the specified patterns will be excluded. Only
+the last specified pattern was previously taken into account.
+
+Digital Signature Verification
+******************************
+
+A new command ``bzr verify-signatures`` has been added to check that commits
+are correctly signed with trusted keys by GPG. This requires python-gpgme to
+be installed. ``bzr log`` has gained a ``--signatures`` option to list the
+validity of signatures for each commit. New config options ``acceptable_keys``
+and ``validate_signatures_in_log`` can be set to control options to these
+commands.
+
+Further information
+*******************
+
+For more detailed information on the changes made, see the the
+:doc:`../release-notes/index` for:
+
+* the interim bzr `milestones <https://launchpad.net/bzr/2.4>`_
+* the plugins you use.
+
+For a summary of changes made in earlier releases, see:
+
+* :doc:`whats-new-in-2.1`
+* :doc:`whats-new-in-2.2`
+* :doc:`whats-new-in-2.3`
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/whats-new/whats-new-in-2.5.txt b/doc/en/whats-new/whats-new-in-2.5.txt
new file mode 100644
index 0000000..8d2cffc
--- /dev/null
+++ b/doc/en/whats-new/whats-new-in-2.5.txt
@@ -0,0 +1,165 @@
+*************************
+What's New in Bazaar 2.5?
+*************************
+
+Bazaar 2.5 bas been released on the 24th of February 2012 and marks the
+start of a new long-term-stable series. From here, we will only make bugfix
+releases on the 2.5 series (2.5.1, etc, and support it until April 2017),
+while 2.6 will become our new development series.
+
+This document accumulates a high level summary of what's changed. See the
+:doc:`../release-notes/index` for a full list.
+
+Users are encouraged to upgrade from the other stable series. This
+document outlines the improvements in Bazaar 2.5 vs Bazaar 2.4. As well as
+summarizing improvements made to the core product, it highlights
+enhancements within the broader Bazaar world of potential interest to
+those upgrading.
+
+Bazaar 2.5.0 is fully compatible both locally and on the network with 2.0,
+2.1, 2.2, 2.3 and 2.4, and can read and write repositories generated by all
+previous versions.
+
+Bazaar 2.5.1 includes all the fixes in the un-released 2.0.7, 2.1.5, 2.2.6,
+2.3.5 and 2.4.3 versions that weren't included in 2.5.0 and fixes some bugs
+on its own.
+
+Overriding configuration options from the command line
+******************************************************
+
+The ``-O`` parameter available for all bzr commands allows a user to
+override a configuration option from the command line. For example::
+
+ bzr pull -v -Olog_format=line
+
+will change the way the pulled revisions are displayed (the default log
+format is ``long``). This a work in progress and only some options are
+supported so far.
+
+Working on a posix system without a locale
+******************************************
+
+Previously bzr needed a valid locale set to work with branches containing
+non-ascii filenames. It will now use utf-8 rather than ascii as a fallback
+encoding for interacting with the filesystem. This makes creating a working
+tree and commiting to it possible for such branches in most environments.
+
+SSL Certificate Verification Support in urllib HTTPS backend
+************************************************************
+
+In previous versions of Bazaar, only one of the two supported HTTPS
+backends, pycurl, supported verification of SSL certificates. This version
+also introduces this support for the urllib backend.
+
+Along with this support two new options have been introduced to control
+which CA's are trusted and to what degree server certificates should be
+verified. See ``bzr help ssl.ca_certs`` and ``bzr help ssl.cert_reqs``
+for more information
+
+Users who have previously used the urllib HTTPS backend with servers
+with invalid or untrusted certificates can continue to do so by
+adding the required certificates to the trusted CA certificate file
+(recommended) or by setting the ``ssl.cert_reqs`` option to ``none``.
+
+Faster smart server
+*******************
+
+A large number of new methods have been added to the smart server, making
+raw file access through the VFS unnecessary in almost all situations, with
+the major exception of operations involving stacked branches.
+
+Commands that have become significantly faster when using a remote branch
+over ``bzr://``, ``bzr+ssh://`` or ``bzr+http://`` include:
+
+ * ``bzr checkout --lightweight``
+ * ``bzr export``
+ * ``bzr cat``
+ * ``bzr ls``
+ * ``bzr send``
+
+Several commands which used to make multiple connections to the server now
+make only a single one. Connection setup has a fairly high overhead,
+especially to Launchpad, so this can save several seconds for some
+commands.
+
+To benefit from the improved smart server, both the server and the
+client need to be running bzr 2.5.
+
+Basic colocated branch support
+******************************
+
+The UI now has basic support for colocated branches. In full URLs,
+a specific colocated branch can be specified using URL path segment
+parameters. For example a branch named ``stronk`` could be addressed using
+``http://example.com/path/to/dir,branch=stronk``.
+
+The new ``bzr branches`` command can be used to list all present branches
+in a directory, and indicates what the currently active branch is.
+
+Several commands also accept co-located branch names directly, such as
+``bzr switch``.
+
+Feature flags
+*************
+
+All Bazaar formats now allow setting ``feature flags``. These can be used
+by plugins to extend Bazaar formats and require the presence of particular
+plugins or versions of Bazaar to open them, without having to introduce
+completely new formats.
+
+See ``doc/developers/feature-flags.txt`` for details.
+
+Branch history access
+*********************
+
+Several commands or options that previously required access to the full
+branch history now only access those parts of the history they actually
+need. This significantly improves their performance for branches
+with large histories.
+
+GPG signatures
+**************
+
+A new command ``bzr verify-signatures`` can be used to verify GPG
+signatures made with ``bzr commit`` or the ``bzr sign-my-commits``
+command.
+
+Translations
+************
+
+Most error messages, help topics and other user-visible text can now be
+translated. Initial translations for Russian, Japanese and Spanish exist.
+
+PO merge plugin
+***************
+
+The ``po_merge`` plugin has been added. It provides a merge hook
+to automate merging of changes to gettext template files. Refer to
+``bzr help po_merge`` for documentation on how to
+enable it and what it can do.
+
+Documentation in texinfo format
+*******************************
+
+Sphinx (>= 1.1.2) provides a better texinfo builder than the alpha-quality
+one provided with bzr sources. Most of the bzr documentation can be
+processed and produce valid ``.info`` files.
+
+Further information
+*******************
+
+For more detailed information on the changes made, see the the
+:doc:`../release-notes/index` for:
+
+* the interim bzr `milestones <https://launchpad.net/bzr/2.5>`_
+* the plugins you use.
+
+For a summary of changes made in earlier releases, see:
+
+* :doc:`whats-new-in-2.1`
+* :doc:`whats-new-in-2.2`
+* :doc:`whats-new-in-2.3`
+* :doc:`whats-new-in-2.4`
+
+..
+ vim: tw=74 ft=rst ff=unix
diff --git a/doc/en/whats-new/whats-new-in-2.6.txt b/doc/en/whats-new/whats-new-in-2.6.txt
new file mode 100644
index 0000000..c0ea930
--- /dev/null
+++ b/doc/en/whats-new/whats-new-in-2.6.txt
@@ -0,0 +1,36 @@
+*************************
+What's New in Bazaar 2.6?
+*************************
+
+Bazaar 2.6 is still under development, and will be released in Auguest 2012.
+This document accumulates a high level summary of what's changed. See the
+:doc:`../release-notes/index` for a full list.
+
+Users are encouraged to upgrade from the other stable series. This document
+outlines the improvements in Bazaar 2.6 vs Bazaar 2.5. As well as
+summarizing improvements made to the core product, it highlights
+enhancements within the broader Bazaar world of potential interest to those
+upgrading.
+
+Bazaar 2.5.0 is fully compatible both locally and on the network with 2.0,
+2.1, 2.2, 2.3, 2.4 and 2.5, and can read and write repositories generated by
+all previous versions.
+
+<topics of interest here>
+
+Further information
+*******************
+
+For more detailed information on the changes made, see the the
+:doc:`../release-notes/index` for:
+
+* the interim bzr `milestones <https://launchpad.net/bzr/2.6>`_
+* the plugins you use.
+
+For a summary of changes made in earlier releases, see:
+
+* :doc:`whats-new-in-2.1`
+* :doc:`whats-new-in-2.2`
+* :doc:`whats-new-in-2.3`
+* :doc:`whats-new-in-2.4`
+* :doc:`whats-new-in-2.5`
diff --git a/doc/es/_static/bzr icon 16.png b/doc/es/_static/bzr icon 16.png
new file mode 100644
index 0000000..0c8d454
--- /dev/null
+++ b/doc/es/_static/bzr icon 16.png
Binary files differ
diff --git a/doc/es/_static/bzr.ico b/doc/es/_static/bzr.ico
new file mode 100644
index 0000000..a49eb7e
--- /dev/null
+++ b/doc/es/_static/bzr.ico
Binary files differ
diff --git a/doc/es/_static/es/Makefile b/doc/es/_static/es/Makefile
new file mode 100644
index 0000000..7b0e591
--- /dev/null
+++ b/doc/es/_static/es/Makefile
@@ -0,0 +1,19 @@
+TARGETS=bzr-es-quick-reference.png bzr-es-quick-reference.pdf
+OBJECTS=bzr-es-quick-reference.svg Makefile
+
+all: $(TARGETS)
+
+.SUFFIXES: .svg .png .pdf
+
+.svg.pdf:
+ rsvg-convert -d 300 -p 300 -f pdf -o $@ $<
+
+.svg.png:
+ rsvg-convert -d 300 -p 300 -z 3.3346 -f png -o $@ $<
+
+bzr-es-quick-reference.png: $(OBJECTS)
+
+bzr-es-quick-reference.pdf: $(OBJECTS)
+
+clean:
+ rm -f $(TARGETS)
diff --git a/doc/es/_static/es/bzr-es-quick-reference.pdf b/doc/es/_static/es/bzr-es-quick-reference.pdf
new file mode 100644
index 0000000..baa279a
--- /dev/null
+++ b/doc/es/_static/es/bzr-es-quick-reference.pdf
Binary files differ
diff --git a/doc/es/_static/es/bzr-es-quick-reference.png b/doc/es/_static/es/bzr-es-quick-reference.png
new file mode 100644
index 0000000..af817f9
--- /dev/null
+++ b/doc/es/_static/es/bzr-es-quick-reference.png
Binary files differ
diff --git a/doc/es/_static/es/bzr-es-quick-reference.svg b/doc/es/_static/es/bzr-es-quick-reference.svg
new file mode 100644
index 0000000..501a537
--- /dev/null
+++ b/doc/es/_static/es/bzr-es-quick-reference.svg
@@ -0,0 +1,1691 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2766"
+ sodipodi:version="0.32"
+ inkscape:version="0.46"
+ version="1.0"
+ sodipodi:docbase="/home/ian/bzr/repo.packs/bzr.quick-start-tweaks/doc/en/quick-reference"
+ sodipodi:docname="referencia-rapida.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/iacobs/work/pers/bzr-quickref.png"
+ inkscape:export-xdpi="300"
+ inkscape:export-ydpi="300">
+ <defs
+ id="defs2768">
+ <inkscape:perspective
+ sodipodi:type="inkscape:persp3d"
+ inkscape:vp_x="0 : 372.04724 : 1"
+ inkscape:vp_y="0 : 1000 : 0"
+ inkscape:vp_z="1052.3622 : 372.04724 : 1"
+ inkscape:persp3d-origin="526.18109 : 248.03149 : 1"
+ id="perspective2680" />
+ <linearGradient
+ id="linearGradient3382">
+ <stop
+ style="stop-color:#2753b0;stop-opacity:1;"
+ offset="0"
+ id="stop3384" />
+ <stop
+ style="stop-color:#cecece;stop-opacity:1;"
+ offset="1"
+ id="stop3386" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5465"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5473"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5603"
+ gradientUnits="userSpaceOnUse"
+ x1="150.39197"
+ y1="104.09448"
+ x2="151.10625"
+ y2="155.92776"
+ gradientTransform="translate(0,26)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient5605"
+ gradientUnits="userSpaceOnUse"
+ x1="165.19594"
+ y1="104.09448"
+ x2="165.19594"
+ y2="156.84296"
+ gradientTransform="translate(0,26)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient8696"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient8704"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ gradientTransform="matrix(1.027169,0,0,1,118.6039,77.1455)"
+ gradientUnits="userSpaceOnUse"
+ y2="0"
+ x2="372.24512"
+ y1="69.037941"
+ x1="372.24512"
+ id="linearGradient2200"
+ xlink:href="#linearGradient5444"
+ inkscape:collect="always" />
+ <linearGradient
+ id="linearGradient5444">
+ <stop
+ style="stop-color:#729fcf;stop-opacity:1;"
+ offset="0"
+ id="stop5446" />
+ <stop
+ id="stop4547"
+ offset="0.5"
+ style="stop-color:#3465a4;stop-opacity:1;" />
+ <stop
+ style="stop-color:#204ab7;stop-opacity:1;"
+ offset="1"
+ id="stop5448" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient5444"
+ id="linearGradient3338"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.027169,0,0,1,417.31189,-41.4259)"
+ x1="372.24512"
+ y1="69.037941"
+ x2="372.24512"
+ y2="0" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3769"
+ gradientUnits="userSpaceOnUse"
+ x1="401.62418"
+ y1="104.09448"
+ x2="402.0069"
+ y2="152.69125"
+ gradientTransform="matrix(1.0959218,0,0,0.9988328,-30.458554,26.145213)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3771"
+ gradientUnits="userSpaceOnUse"
+ x1="401.62418"
+ y1="104.09448"
+ x2="402.0069"
+ y2="152.69125"
+ gradientTransform="matrix(1.0959218,0,0,0.9988328,-30.458554,26.145213)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3824"
+ gradientUnits="userSpaceOnUse"
+ x1="625.15149"
+ y1="104.09448"
+ x2="625.15149"
+ y2="154.2104"
+ gradientTransform="matrix(1.0902791,0,0,0.9988999,-49.120159,26.136854)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3826"
+ gradientUnits="userSpaceOnUse"
+ x1="625.15149"
+ y1="104.09448"
+ x2="625.15149"
+ y2="154.2104"
+ gradientTransform="matrix(1.0902791,0,0,0.9988999,-49.120159,26.136854)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3956"
+ gradientUnits="userSpaceOnUse"
+ x1="852.71942"
+ y1="104.09448"
+ x2="852.71942"
+ y2="153.842"
+ gradientTransform="matrix(1.0836855,0,0,0.9989026,-64.492287,26.135003)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3958"
+ gradientUnits="userSpaceOnUse"
+ x1="852.71942"
+ y1="104.09448"
+ x2="852.71942"
+ y2="153.842"
+ gradientTransform="matrix(1.0836855,0,0,0.9989026,-64.492287,26.135003)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient4035"
+ gradientUnits="userSpaceOnUse"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient4037"
+ gradientUnits="userSpaceOnUse"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient4042"
+ gradientUnits="userSpaceOnUse"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879"
+ gradientTransform="matrix(1.073884,0,0,0.9990288,-56.948006,16.382016)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient4044"
+ gradientUnits="userSpaceOnUse"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879"
+ gradientTransform="matrix(1.073884,0,0,0.9990288,-56.948006,16.382016)" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2734"
+ gradientUnits="userSpaceOnUse"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2736"
+ gradientUnits="userSpaceOnUse"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2741"
+ gradientUnits="userSpaceOnUse"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2743"
+ gradientUnits="userSpaceOnUse"
+ x1="164.4165"
+ y1="380.09448"
+ x2="164.4165"
+ y2="436.59479" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2723"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.073884,0,0,0.9990288,-56.948006,16.382016)"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2725"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.073884,0,0,0.9990288,-56.948006,16.382016)"
+ x1="814.96497"
+ y1="364.08444"
+ x2="814.96497"
+ y2="412.09879" />
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.93888816"
+ inkscape:cx="632.57173"
+ inkscape:cy="82.468477"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09449px"
+ inkscape:showpageshadow="false"
+ showgrid="false"
+ inkscape:window-width="1023"
+ inkscape:window-height="719"
+ inkscape:window-x="1"
+ inkscape:window-y="24" />
+ <metadata
+ id="metadata2771">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <cc:license
+ rdf:resource="http://creativecommons.org/licenses/GPL/2.0/" />
+ <dc:title>Bazaar-NG quick reference</dc:title>
+ <dc:date>2007-07-23</dc:date>
+ <dc:creator>
+ <cc:Agent>
+ <dc:title>Sabin Iacob</dc:title>
+ </cc:Agent>
+ </dc:creator>
+ <dc:language>en</dc:language>
+ <dc:subject>
+ <rdf:Bag>
+ <rdf:li>bzr</rdf:li>
+ <rdf:li>bazaar</rdf:li>
+ <rdf:li>reference</rdf:li>
+ </rdf:Bag>
+ </dc:subject>
+ </cc:Work>
+ <cc:License
+ rdf:about="http://creativecommons.org/licenses/GPL/2.0/">
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/Reproduction" />
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/Distribution" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/Notice" />
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/ShareAlike" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/SourceCode" />
+ </cc:License>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <rect
+ style="opacity:1;fill:none;fill-opacity:0;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect2983"
+ width="1052.1749"
+ height="744"
+ x="0"
+ y="0.094482422"
+ ry="0" />
+ <g
+ id="g3762">
+ <g
+ id="g8706">
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect2190"
+ width="228.60797"
+ height="216.41451"
+ x="50.891964"
+ y="144.31995"
+ ry="8.1168776" />
+ <path
+ style="fill:url(#linearGradient5603);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient5605);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 59.296663,130.59448 C 54.644771,130.59448 50.891959,134.22213 50.891959,138.71888 L 50.891959,167.43551 C 50.891959,162.93876 54.644771,159.31111 59.296663,159.31111 L 271.12755,159.31111 C 275.77946,159.31111 279.49993,162.93876 279.49993,167.43551 L 279.49993,138.71888 C 279.49993,134.22213 275.77946,130.59448 271.12755,130.59448 L 59.296663,130.59448 z "
+ id="rect3430" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="108.32876"
+ y="150.97269"
+ id="text3164"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3166"
+ x="108.32876"
+ y="150.97269">Inicialización</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-2.2095387)"
+ id="g3209">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="63.794312"
+ y="193.07361"
+ id="text2167"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="63.794312"
+ y="193.07361"
+ id="tspan2171">bzr init miproyecto</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="179.83536"
+ id="text3168"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3170"
+ x="58.209351"
+ y="179.83536">Proyecto nuevo</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.1449276)"
+ id="g3215">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="226.45848"
+ id="text2175"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan2177"
+ x="64.448624"
+ y="226.45848">cd miproyecto</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="237.53181"
+ id="tspan2179">bzr init</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="248.60515"
+ id="tspan2181">bzr add .</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="259.67847"
+ id="tspan2183" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.174194"
+ y="213.22023"
+ id="text3172"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3174"
+ x="58.174194"
+ y="213.22023">Proyecto existente</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,5.3457864e-2)"
+ id="g3224">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="277.48495"
+ id="text2185"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan2187"
+ x="64.448624"
+ y="277.48495">bzr branch mp miproyecto</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="266.6666"
+ id="text3176"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3178"
+ x="58.209351"
+ y="266.6666">Nuevo branch</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,1.1181147)"
+ id="g3230">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="308.44989"
+ id="text3404"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3406"
+ x="64.448624"
+ y="308.44989">bzr checkout mp miproyecto</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="297.63153"
+ id="text3408"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3410"
+ x="58.209351"
+ y="297.63153">Nuevo checkout</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,2.1828937)"
+ id="g3236">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="64.448624"
+ y="341.88864"
+ id="text3414"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan3424"
+ sodipodi:role="line"
+ x="64.448624"
+ y="341.88864">bzr checkout --lightweight mp \</tspan><tspan
+ sodipodi:role="line"
+ x="64.448624"
+ y="352.96198"
+ id="tspan2780"> miproyecto</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="58.209351"
+ y="328.59634"
+ id="text3418"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan3422"
+ sodipodi:role="line"
+ x="58.209351"
+ y="328.59634">Nuevo checkout &quot;ligero&quot;</tspan></text>
+ </g>
+ </g>
+ <g
+ id="g3774">
+ <rect
+ ry="9.6319456"
+ y="145.57634"
+ x="317.80582"
+ height="135.65298"
+ width="206.32903"
+ id="rect3658"
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1.0466845;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <path
+ id="rect3648"
+ d="M 328.38206,130.61761 C 322.53211,130.61761 317.79957,134.89967 317.79957,140.23137 L 317.79957,170.19635 C 317.79957,164.86465 322.53211,160.58259 328.38206,160.58259 L 513.59284,160.58259 C 519.4428,160.58259 524.14109,164.86465 524.14109,170.19635 L 524.14109,140.23137 C 524.14109,134.89967 519.4428,130.61761 513.59284,130.61761 L 328.38206,130.61761 z"
+ style="fill:url(#linearGradient3769);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient3771);stroke-width:1.04625165;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text3563"
+ y="150.94995"
+ x="333.44049"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="150.94995"
+ x="333.44049"
+ id="tspan3565"
+ sodipodi:role="line">Manipular Archivos</tspan></text>
+ <g
+ transform="translate(1e-4,-1.9729054)"
+ id="g3243">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="332.47345"
+ y="191.36041"
+ id="text3610"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="332.47345"
+ y="191.36041"
+ id="tspan3612">bzr add foo.py</tspan><tspan
+ id="tspan3618"
+ sodipodi:role="line"
+ x="332.47345"
+ y="202.43375">bzr add bar/</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="326.88849"
+ y="179.59872"
+ id="text3614"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3616"
+ x="326.88849"
+ y="179.59872">Añadir/&quot;versionar&quot; archivos</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-0.9323495)"
+ id="g3250">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="331.78732"
+ y="233.11641"
+ id="text3622"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="331.78732"
+ y="233.11641"
+ id="tspan3624">bzr remove --keep foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="326.20236"
+ y="221.35472"
+ id="text3626"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3628"
+ x="326.20236"
+ y="221.35472">Eliminar archivos</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,0.1322158)"
+ id="g3256">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="331.81714"
+ y="264.08142"
+ id="text3632"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="331.81714"
+ y="264.08142"
+ id="tspan3634">bzr remove --force foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="326.23218"
+ y="253.26308"
+ id="text3636"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3638"
+ x="326.23218"
+ y="253.26308">Eliminar y borrar archivos</tspan></text>
+ </g>
+ </g>
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1.02624357;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3780"
+ width="229.91788"
+ height="336.27368"
+ x="49.457561"
+ y="394.44012"
+ ry="10.484502" />
+ <path
+ style="fill:url(#linearGradient2741);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient2743);stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 57.795026,380.59448 C 53.111409,380.59448 49.333004,384.22215 49.333004,388.71892 L 49.333004,417.43572 C 49.333004,412.93894 53.111409,409.31127 57.795026,409.31127 L 271.07052,409.31127 C 275.75416,409.31127 279.5,412.93894 279.5,417.43572 L 279.5,388.71892 C 279.5,384.22215 275.75416,380.59448 271.07052,380.59448 L 57.795026,380.59448 z"
+ id="path3784" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="111.15869"
+ y="400.96985"
+ id="text3786"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3788"
+ x="111.15869"
+ y="400.96985">Información</tspan></text>
+ <g
+ id="g3281"
+ transform="translate(1e-4,0.4441055)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3234"
+ y="441.34354"
+ x="62.69976"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan3236"
+ y="441.34354"
+ x="62.69976"
+ sodipodi:role="line">bzr status</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3238"
+ y="428.10529"
+ x="57.114799"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="428.10529"
+ x="57.114799"
+ id="tspan3240"
+ sodipodi:role="line">Estado del árbol de trabajo</tspan></text>
+ </g>
+ <g
+ id="g3287"
+ transform="translate(1e-4,1.4958392)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3244"
+ y="472.84393"
+ x="62.721241"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan3250"
+ y="472.84393"
+ x="62.721241"
+ sodipodi:role="line">bzr log</tspan><tspan
+ y="483.91727"
+ x="62.721241"
+ sodipodi:role="line"
+ id="tspan3294">bzr log foo.py</tspan><tspan
+ id="tspan3252"
+ y="494.9906"
+ x="62.721241"
+ sodipodi:role="line" /></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3254"
+ y="459.55164"
+ x="56.446827"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="459.55164"
+ x="56.446827"
+ id="tspan3256"
+ sodipodi:role="line">Log de revisión</tspan></text>
+ </g>
+ <g
+ id="g3295"
+ transform="translate(1e-4,2.6343158)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3260"
+ y="517.29712"
+ x="63.354061"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="517.29712"
+ x="63.354061"
+ id="tspan3262"
+ sodipodi:role="line">bzr diff</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3264"
+ y="504.05884"
+ x="57.114803"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="504.05884"
+ x="57.114803"
+ id="tspan3266"
+ sodipodi:role="line">Cambios en el árbol de trabajo</tspan></text>
+ </g>
+ <g
+ id="g3314"
+ transform="translate(1e-4,5.8149666)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3298"
+ y="625.09357"
+ x="62.744678"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="625.09357"
+ x="62.744678"
+ id="tspan3300"
+ sodipodi:role="line">bzr missing</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3302"
+ y="611.85535"
+ x="56.505421"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="611.85535"
+ x="56.505421"
+ id="tspan3304"
+ sodipodi:role="line">Revisiones perdidas</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.7565"
+ y="707.22107"
+ id="text3308"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3310"
+ x="62.7565"
+ y="707.22107">bzr cat -r3 foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.517242"
+ y="682.26678"
+ id="text3312"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ x="56.517242"
+ y="682.26678"
+ id="tspan3625">Contenidos de foo.py en la </tspan><tspan
+ sodipodi:role="line"
+ x="56.517242"
+ y="694.26678"
+ id="tspan3681">revisión 3</tspan></text>
+ <g
+ id="g3320"
+ transform="translate(1e-4,6.8799266)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3318"
+ y="656.12701"
+ x="62.686089"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="656.12701"
+ x="62.686089"
+ id="tspan3320"
+ sodipodi:role="line">bzr info</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3322"
+ y="645.30865"
+ x="56.446831"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="645.30865"
+ x="56.446831"
+ id="tspan3324"
+ sodipodi:role="line">Información del branch</tspan></text>
+ </g>
+ <g
+ id="g3301"
+ transform="translate(1e-4,3.685897)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3330"
+ y="548.74365"
+ x="62.879452"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="548.74365"
+ x="62.879452"
+ id="tspan3332"
+ sodipodi:role="line">bzr diff foo.py</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3334"
+ y="535.50537"
+ x="56.640194"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="535.50537"
+ x="56.640194"
+ id="tspan3336"
+ sodipodi:role="line">Cambios en foo.py </tspan></text>
+ </g>
+ <g
+ id="g3307"
+ transform="translate(1e-4,4.7504623)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3699"
+ y="591.70862"
+ x="62.000679"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="591.70862"
+ x="62.000679"
+ id="tspan3701"
+ sodipodi:role="line">bzr diff -r1..3 foo.py</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3703"
+ y="568.89032"
+ x="55.761421"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="568.89032"
+ x="55.761421"
+ id="tspan3705"
+ sodipodi:role="line">Cambios en foo.py entre las</tspan><tspan
+ y="580.89032"
+ x="55.761421"
+ sodipodi:role="line"
+ id="tspan3707">revisiones 1 y 3</tspan></text>
+ </g>
+ <g
+ id="g3829">
+ <rect
+ ry="9.6321363"
+ y="145.575"
+ x="544.36224"
+ height="135.65567"
+ width="205.26662"
+ id="rect4132"
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1.04399669;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <path
+ id="path4130"
+ d="M 554.88401,130.61628 C 549.06418,130.61628 544.35601,134.89863 544.35601,140.23069 L 544.35601,170.19768 C 544.35601,164.86563 549.06418,160.58327 554.88401,160.58327 L 739.14116,160.58327 C 744.96101,160.58327 749.6351,164.86563 749.6351,170.19768 L 749.6351,140.23069 C 749.6351,134.89863 744.96101,130.61628 739.14116,130.61628 L 554.88401,130.61628 z"
+ style="fill:url(#linearGradient3824);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient3826);stroke-width:1.04358983;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text4134"
+ y="152.01505"
+ x="554.46985"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="152.01505"
+ x="554.46985"
+ id="tspan4136"
+ sodipodi:role="line">Control de Versiones</tspan></text>
+ <g
+ transform="translate(1e-4,-2.4445851)"
+ id="g3262">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="559.03162"
+ y="190.88873"
+ id="text4140"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="559.03162"
+ y="190.88873"
+ id="tspan4142">bzr commit foo.py -m &quot;foo&quot;</tspan><tspan
+ id="tspan4144"
+ sodipodi:role="line"
+ x="559.03162"
+ y="201.96207">bzr commit -m &quot;el resto&quot;</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="553.44666"
+ y="180.0704"
+ id="text4146"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4148"
+ x="553.44666"
+ y="180.0704">Commit</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-2.6967609)"
+ id="g3269">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="558.37482"
+ y="232.2924"
+ id="text4152"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="558.37482"
+ y="232.2924"
+ id="tspan4154">bzr uncommit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="552.78986"
+ y="221.47408"
+ id="text4156"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4158"
+ x="552.78986"
+ y="221.47408">Deshacer último commit</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,-1.6451646)"
+ id="g3275">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="558.37488"
+ y="263.73889"
+ id="text4162"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="558.37488"
+ y="263.73889"
+ id="tspan4164">bzr revert</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="552.78992"
+ y="250.50064"
+ id="text4166"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4168"
+ x="552.78992"
+ y="250.50064">Revertir los cambios</tspan></text>
+ </g>
+ </g>
+ <g
+ id="g3961">
+ <rect
+ ry="8.1153431"
+ y="144.34038"
+ x="770.91241"
+ height="216.37361"
+ width="247.73869"
+ id="rect4232"
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1.04090285;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <path
+ id="path4234"
+ d="M 780.02026,130.6147 C 774.97907,130.6147 770.91221,134.23836 770.91221,138.73017 L 770.91221,167.41528 C 770.91221,162.92347 774.97907,159.2998 780.02026,159.2998 L 1009.5783,159.2998 C 1014.6195,159.2998 1018.6514,162.92347 1018.6514,167.41528 L 1018.6514,138.73017 C 1018.6514,134.23836 1014.6195,130.6147 1009.5783,130.6147 L 780.02026,130.6147 z"
+ style="fill:url(#linearGradient3956);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient3958);stroke-width:1.04043078;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <text
+ sodipodi:linespacing="100%"
+ id="text4236"
+ y="149.90759"
+ x="796.75134"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="149.90759"
+ x="796.75134"
+ id="tspan4238"
+ sodipodi:role="line">Merging / Integrando</tspan></text>
+ <g
+ transform="translate(1e-4,-1.0888417)"
+ id="g3392">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="783.75751"
+ y="191.95291"
+ id="text4242"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="783.75751"
+ y="191.95291"
+ id="tspan4244">cd miproyecto</tspan><tspan
+ sodipodi:role="line"
+ x="783.75751"
+ y="203.02625"
+ id="tspan4296">bzr merge ../miproyecto-foo</tspan><tspan
+ sodipodi:role="line"
+ x="783.75751"
+ y="214.09958"
+ id="tspan4298">bzr commit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17255"
+ y="178.71466"
+ id="text4246"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4248"
+ x="778.17255"
+ y="178.71466">Integrar dos branches</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,0.1095133)"
+ id="g3384">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.44696"
+ y="245.39931"
+ id="text4252"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4254"
+ x="784.44696"
+ y="245.39931">cd miproyecto-foo</tspan><tspan
+ sodipodi:role="line"
+ x="784.44696"
+ y="256.47263"
+ id="tspan4258">bzr pull ../miproyecto</tspan><tspan
+ sodipodi:role="line"
+ x="784.44696"
+ y="267.54596"
+ id="tspan4260" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17255"
+ y="232.16106"
+ id="text4262"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4264"
+ x="778.17255"
+ y="232.16106">Pull de cambios desde miproyecto</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,1.2474884)"
+ id="g3378">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.4118"
+ y="289.69043"
+ id="text4268"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4270"
+ x="784.4118"
+ y="289.69043">bzr update</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17255"
+ y="276.5459"
+ id="text4272"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4274"
+ x="778.17255"
+ y="276.5459">Actualizar un checkout</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,2.3122978)"
+ id="g3372">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="785.45477"
+ y="320.70923"
+ id="text4278"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4280"
+ x="785.45477"
+ y="320.70923">bzr resolve</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="779.21552"
+ y="309.83685"
+ id="text4282"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4284"
+ x="779.21552"
+ y="309.83685">Autodetectar conflictos resueltos</tspan></text>
+ </g>
+ <g
+ transform="translate(1e-4,3.3643062)"
+ id="g3366">
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.65204"
+ y="352.20935"
+ id="text4288"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan4290"
+ sodipodi:role="line"
+ x="784.65204"
+ y="352.20935">bzr resolve foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.41278"
+ y="338.91705"
+ id="text4292"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan4294"
+ sodipodi:role="line"
+ x="778.41278"
+ y="338.91705">Especificar un conflicto resuelto</tspan></text>
+ </g>
+ </g>
+ <rect
+ style="fill:none;fill-opacity:0;fill-rule:nonzero;stroke:#cecece;stroke-width:1.06177783;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect4531"
+ width="246.92378"
+ height="335.17307"
+ x="771.16052"
+ y="394.45789"
+ ry="10.450186" />
+ <path
+ style="fill:url(#linearGradient2723);fill-opacity:1;fill-rule:nonzero;stroke:url(#linearGradient2725);stroke-width:1.03578043;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ d="M 780.12335,380.61237 C 775.09368,380.61237 771.03611,384.23652 771.03611,388.72892 L 771.03611,417.41783 C 771.03611,412.92542 775.09368,409.30127 780.12335,409.30127 L 1009.1565,409.30127 C 1014.1862,409.30127 1018.2087,412.92542 1018.2087,417.41783 L 1018.2087,388.72892 C 1018.2087,384.23652 1014.1862,380.61237 1009.1565,380.61237 L 780.12335,380.61237 z"
+ id="path4533" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="844.98444"
+ y="399.90475"
+ id="text4535"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4537"
+ x="844.98444"
+ y="399.90475">Publicando</tspan></text>
+ <g
+ id="g3354"
+ transform="translate(1e-4,-1.7634544)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4616"
+ y="475.58072"
+ x="781.75745"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan4618"
+ y="475.58072"
+ x="781.75745"
+ sodipodi:role="line">bzr push sftp://host/miproyecto-fo1</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4620"
+ y="462.34244"
+ x="776.17249"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="462.34244"
+ x="776.17249"
+ id="tspan4622"
+ sodipodi:role="line">Empujar revisiones remotamente</tspan></text>
+ </g>
+ <g
+ id="g3360"
+ transform="translate(1e-4,-1.1779953)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4457"
+ y="440.54575"
+ x="782.38519"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan4459"
+ y="440.54575"
+ x="782.38519"
+ sodipodi:role="line">bzr push ../miproyecto-fo1</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4461"
+ y="429.72739"
+ x="776.80023"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="429.72739"
+ x="776.80023"
+ id="tspan4463"
+ sodipodi:role="line">Push de revisiones</tspan></text>
+ </g>
+ <g
+ id="g3346"
+ transform="translate(1e-4,0.3362061)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4467"
+ y="505.56467"
+ x="782.40674"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="505.56467"
+ x="782.40674"
+ sodipodi:role="line"
+ id="tspan8805">bzr send</tspan><tspan
+ id="tspan4473"
+ y="516.638"
+ x="782.40674"
+ sodipodi:role="line" /></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4475"
+ y="494.69229"
+ x="776.13232"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="494.69229"
+ x="776.13232"
+ sodipodi:role="line"
+ id="tspan4608">Enviar por Email directriz merge</tspan></text>
+ </g>
+ <g
+ id="g3339"
+ transform="translate(1e-4,31.004958)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4481"
+ y="562.4187"
+ x="783.03955"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="562.4187"
+ x="783.03955"
+ id="tspan4483"
+ sodipodi:role="line">bzr export ../miproyecto-dist/</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4485"
+ y="537.18048"
+ x="776.80029"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="537.18048"
+ x="776.80029"
+ id="tspan4487"
+ sodipodi:role="line">Exportar la revisión actual como</tspan><tspan
+ y="549.18048"
+ x="776.80029"
+ sodipodi:role="line"
+ id="tspan4610">un directorio</tspan></text>
+ </g>
+ <g
+ id="g3332"
+ transform="translate(1e-4,33.600285)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4521"
+ y="605.85291"
+ x="782.565"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="605.85291"
+ x="782.565"
+ id="tspan4523"
+ sodipodi:role="line">bzr export ../miproyecto-dist.zip</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4525"
+ y="583.03461"
+ x="776.32574"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="583.03461"
+ x="776.32574"
+ id="tspan4527"
+ sodipodi:role="line">Exportar la revisión actual como</tspan><tspan
+ y="595.03461"
+ x="776.32574"
+ sodipodi:role="line"
+ id="tspan4612">un archivo</tspan></text>
+ </g>
+ <g
+ id="g2446"
+ transform="translate(-1.4135726,38.47762)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text2448"
+ y="505.56467"
+ x="782.40674"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="505.56467"
+ x="782.40674"
+ sodipodi:role="line"
+ id="tspan2450">bzr send -o ../base.patch</tspan><tspan
+ id="tspan2452"
+ y="516.638"
+ x="782.40674"
+ sodipodi:role="line" /></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text2454"
+ y="494.69229"
+ x="776.13232"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="494.69229"
+ x="776.13232"
+ sodipodi:role="line"
+ id="tspan2456">Crear una directriz merge</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="144.32812"
+ y="64.254639"
+ id="text2774"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan2776"
+ x="144.32812"
+ y="64.254639">Bazaar </tspan></text>
+ <g
+ style="display:inline"
+ id="g3653"
+ transform="matrix(0.6461515,0,0,0.6526216,160.93614,144.01237)"
+ inkscape:export-filename="/home/matt/Projects/Ubuntu/Bazaar Website/bzr icon 64.png"
+ inkscape:export-xdpi="45.012665"
+ inkscape:export-ydpi="45.012665">
+ <path
+ id="path2749"
+ d="M -143.51431,-75.4275 C -158.48768,-90.57687 -171.17625,-103.66019 -171.7111,-104.50153 C -174.63909,-109.10738 -172.34363,-112.16647 -143.7155,-141.81059 C -119.96256,-166.4065 -114.08422,-171.84722 -111.26302,-171.84722 C -108.45655,-171.84722 -102.57922,-166.49332 -79.566158,-142.97326 C -59.704508,-122.67403 -51.314608,-113.24681 -51.314608,-111.22876 C -51.314608,-107.03298 -109.21126,-47.88319 -113.31814,-47.88319 C -115.49463,-47.88319 -123.57621,-55.25503 -143.51431,-75.4275 z "
+ style="opacity:1;fill:#fce94f;fill-opacity:1;stroke:#fce94f;stroke-width:4;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline" />
+ <path
+ id="path2721"
+ d="M -118.75152,-74.850683 C -119.22012,-75.319283 -119.60352,-85.958443 -119.60352,-98.493313 L -119.60352,-121.28395 L -124.85215,-121.28395 C -131.2088,-121.28395 -131.22918,-121.19503 -121.27316,-136.90004 C -116.77235,-143.99978 -113.38241,-148.09169 -112.19584,-147.85705 C -110.34853,-147.49175 -95.321883,-124.90849 -95.321883,-122.4975 C -95.321883,-121.83004 -97.640303,-121.28395 -100.47393,-121.28395 C -103.84689,-121.28395 -105.87693,-120.6299 -106.35276,-119.38989 C -107.55959,-116.24495 -103.45251,-106.32746 -97.296233,-97.520823 C -90.988133,-88.497013 -90.461803,-86.665103 -93.461883,-84.175253 C -95.128693,-82.791933 -96.185063,-83.268713 -100.25177,-87.239733 C -102.90055,-89.826193 -105.46285,-91.547323 -105.94572,-91.064423 C -106.42862,-90.581523 -106.8237,-86.544203 -106.8237,-82.092573 L -106.8237,-73.998703 L -112.36162,-73.998703 C -115.40746,-73.998703 -118.28294,-74.382103 -118.75152,-74.850683 z "
+ style="opacity:1;fill:#c4a000;fill-opacity:1;stroke:#c4a000;display:inline" />
+ <path
+ id="path2727"
+ d="M -120.75152,-76.85072 C -121.22012,-77.31932 -121.60352,-87.95848 -121.60352,-100.49335 L -121.60352,-123.28399 L -126.85215,-123.28399 C -133.2088,-123.28399 -133.22918,-123.19507 -123.27316,-138.90007 C -118.77235,-145.99981 -115.38241,-150.09172 -114.19584,-149.85708 C -112.34853,-149.49178 -97.321888,-126.90852 -97.321888,-124.49754 C -97.321888,-123.83008 -99.640308,-123.28399 -102.47393,-123.28399 C -105.84689,-123.28399 -107.87693,-122.62994 -108.35276,-121.38993 C -109.55959,-118.24499 -105.45251,-108.3275 -99.296238,-99.52086 C -92.988138,-90.49705 -92.461808,-88.66514 -95.461888,-86.17529 C -97.128698,-84.79197 -98.185068,-85.26875 -102.25177,-89.23977 C -104.90055,-91.82623 -107.46285,-93.54736 -107.94572,-93.06446 C -108.42862,-92.58156 -108.8237,-88.54424 -108.8237,-84.09261 L -108.8237,-75.99874 L -114.36162,-75.99874 C -117.40746,-75.99874 -120.28294,-76.38214 -120.75152,-76.85072 z "
+ style="opacity:1;fill:#555753;fill-opacity:1;stroke:#2e3436;stroke-opacity:1;display:inline" />
+ <path
+ d="M -143.51431,-75.4275 C -158.48768,-90.57687 -171.17625,-103.66019 -171.7111,-104.50153 C -174.63909,-109.10738 -172.34363,-112.16647 -143.7155,-141.81059 C -119.96256,-166.4065 -114.08422,-171.84722 -111.26302,-171.84722 C -108.45655,-171.84722 -102.57922,-166.49332 -79.566162,-142.97326 C -59.704512,-122.67403 -51.314612,-113.24681 -51.314612,-111.22876 C -51.314612,-107.03298 -109.21126,-47.88319 -113.31814,-47.88319 C -115.49463,-47.88319 -123.57621,-55.25503 -143.51431,-75.4275 z M -82.734602,-78.80831 C -63.284082,-98.78654 -53.870592,-109.3496 -53.870592,-111.19708 C -53.870592,-114.35673 -108.28764,-170.68595 -111.26979,-170.61328 C -113.31427,-170.56346 -167.39892,-115.6112 -169.81635,-111.12752 C -171.82156,-107.40842 -170.53236,-105.76188 -145.24612,-79.74648 C -117.66227,-51.36719 -115.36413,-49.16116 -113.38369,-49.16116 C -112.40192,-49.16116 -98.609822,-62.50237 -82.734602,-78.80831 z "
+ style="opacity:1;fill:#555753;fill-opacity:1;stroke:#2e3436;stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline"
+ id="path2736" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="146.57143"
+ y="97.808769"
+ id="text3409"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3411"
+ x="146.57143"
+ y="97.808769">Tarjeta de Referencia Rápida</tspan></text>
+ <g
+ id="g12314"
+ transform="translate(17.946423,1.7472534)"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ sodipodi:linespacing="100%"
+ id="text8833"
+ y="527.43823"
+ x="297.99408"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:#333333;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;font-family:Bitstream Vera Sans"
+ y="527.43823"
+ x="297.99408"
+ id="tspan8835"
+ sodipodi:role="line">Prefijos URL Soportados</tspan></text>
+ <g
+ id="g12288"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="299.33002"
+ y="547.94214"
+ id="text8837"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan8841"
+ x="299.33002"
+ y="547.94214">aftp://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8843"
+ x="299.33002"
+ y="565.94214">bzr://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="583.94214"
+ id="tspan10799">bzr+ssh://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="583.94214"
+ id="tspan3911" /><tspan
+ sodipodi:role="line"
+ id="tspan8847"
+ x="299.33002"
+ y="601.94214">file:// </tspan><tspan
+ sodipodi:role="line"
+ id="tspan8849"
+ x="299.33002"
+ y="619.94214">ftp:// </tspan><tspan
+ sodipodi:role="line"
+ id="tspan8851"
+ x="299.33002"
+ y="637.94214">http://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8853"
+ x="299.33002"
+ y="655.94214">https://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="673.94214"
+ id="tspan10797" /><tspan
+ sodipodi:role="line"
+ id="tspan8855"
+ x="299.33002"
+ y="691.94214">sftp://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8857"
+ x="299.33002"
+ y="709.94214" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;opacity:1;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="379.22845"
+ y="547.94214"
+ id="text12260"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan12262"
+ x="379.22845"
+ y="547.94214">Acceso usando FTP activo.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="565.94214"
+ id="tspan12264">Acceso rápido usando el servidor inteligente de Bazaar.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="583.94214"
+ id="tspan12270">Acceso rápido usando el servidor inteligente de Bazaar</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="601.94214"
+ id="tspan3909">sobre SSH.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="619.94214"
+ id="tspan12286">Accesos usando el sistema de archivos estándar (defecto).</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="637.94214"
+ id="tspan12272">Acceso usando FTP pasivo.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="655.94214"
+ id="tspan12274">Acceso de solo lectura de branches exportadas en la web.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="673.94214"
+ id="tspan12276">Acceso de solo lectura de branches exportadas en la web</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="691.94214"
+ id="tspan12278">utilizando SSL.</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="709.94214"
+ id="tspan12280">Acceso usando SFTP (la mayoría de los servidores SSH</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="727.94214"
+ id="tspan3913">proporcionan SFTP).</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="745.94214"
+ id="tspan12282" /></text>
+ </g>
+ </g>
+ <g
+ id="g3885">
+ <text
+ sodipodi:linespacing="100%"
+ id="text4624"
+ y="320.09448"
+ x="316.78033"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:#333333;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;font-family:Bitstream Vera Sans"
+ y="320.09448"
+ x="316.78033"
+ id="tspan4626"
+ sodipodi:role="line">Conceptos</tspan></text>
+ <text
+ sodipodi:linespacing="150%"
+ id="text12146"
+ y="341.21167"
+ x="477.7457"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="341.21167"
+ x="477.7457"
+ id="tspan12148"
+ sodipodi:role="line">línea de desarrollo para un proyecto</tspan><tspan
+ id="tspan12150"
+ y="359.21167"
+ x="477.7457"
+ sodipodi:role="line">directorio bajo control de versiones</tspan><tspan
+ id="tspan12152"
+ y="377.21167"
+ x="477.7457"
+ sodipodi:role="line">almacén para revisiones de Bazaar</tspan><tspan
+ id="tspan12156"
+ y="395.21167"
+ x="477.7457"
+ sodipodi:role="line">versión del código fuente añadido al</tspan><tspan
+ y="413.21167"
+ x="477.7457"
+ sodipodi:role="line"
+ id="tspan3853">repositorio</tspan><tspan
+ id="tspan12158"
+ y="431.21167"
+ x="477.7457"
+ sodipodi:role="line">revisión con nombre</tspan><tspan
+ id="tspan12160"
+ y="449.21167"
+ x="477.7457"
+ sodipodi:role="line">branches que tienen un ancestro común</tspan><tspan
+ y="467.21167"
+ x="477.7457"
+ sodipodi:role="line"
+ id="tspan3857">la operación de aplicar a un branch todos los </tspan><tspan
+ y="485.21167"
+ x="477.7457"
+ sodipodi:role="line"
+ id="tspan3861">cambios introducidos por otra persona</tspan></text>
+ <text
+ sodipodi:linespacing="150%"
+ id="text12400"
+ y="341.21167"
+ x="317.27643"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="341.21167"
+ x="317.27643"
+ id="tspan12402"
+ sodipodi:role="line">Branch:</tspan><tspan
+ id="tspan12404"
+ y="359.21167"
+ x="317.27643"
+ sodipodi:role="line">Árbol de trabajo:</tspan><tspan
+ id="tspan12406"
+ y="377.21167"
+ x="317.27643"
+ sodipodi:role="line">Repositorio:</tspan><tspan
+ id="tspan12408"
+ y="395.21167"
+ x="317.27643"
+ sodipodi:role="line">Revisión:</tspan><tspan
+ id="tspan12410"
+ y="413.21167"
+ x="317.27643"
+ sodipodi:role="line" /><tspan
+ id="tspan12412"
+ y="431.21167"
+ x="317.27643"
+ sodipodi:role="line">Tag:</tspan><tspan
+ id="tspan12414"
+ y="449.21167"
+ x="317.27643"
+ sodipodi:role="line">Branches relacionadas:</tspan><tspan
+ id="tspan12416"
+ y="467.21167"
+ x="317.27643"
+ sodipodi:role="line">Merge / Integración:</tspan><tspan
+ id="tspan12418"
+ y="485.21167"
+ x="317.27643"
+ sodipodi:role="line"> </tspan></text>
+ </g>
+ <g
+ id="g6327"
+ transform="translate(6.5601196,0)"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ sodipodi:linespacing="100%"
+ id="text6294"
+ y="50.289795"
+ x="775.77582"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;opacity:1;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="50.289795"
+ x="775.77582"
+ id="tspan6296"
+ sodipodi:role="line">Más Información</tspan></text>
+ <g
+ id="g6320"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="787.72699"
+ y="76.095581"
+ id="text6298"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan6300"
+ x="787.72699"
+ y="76.095581">bzr help</tspan></text>
+ <a
+ id="a6316"
+ style="fill:#333333;fill-opacity:1"
+ xlink:href="http://bazaar.canonical.com">
+ <text
+ sodipodi:linespacing="100%"
+ id="text6302"
+ y="97.901367"
+ x="787.79535"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="97.901367"
+ x="787.79535"
+ id="tspan6304"
+ sodipodi:role="line">http://bazaar.canonical.com</tspan></text>
+ </a>
+ </g>
+ </g>
+ </g>
+</svg>
diff --git a/doc/es/_templates/layout.html b/doc/es/_templates/layout.html
new file mode 100644
index 0000000..dee0234
--- /dev/null
+++ b/doc/es/_templates/layout.html
@@ -0,0 +1,8 @@
+{% extends "!layout.html" %}
+
+{% block rootrellink %}
+<li><a href="http://bazaar.canonical.com/">
+ <img src="{{ pathto("_static/bzr icon 16.png", 1) }}" /> Inicio</a>&nbsp;|&nbsp;</li>
+<a href="http://doc.bazaar.canonical.com/">Documentación</a>&nbsp;|&nbsp;</li>
+{{ super() }}
+{% endblock %}
diff --git a/doc/es/conf.py b/doc/es/conf.py
new file mode 100644
index 0000000..bc0aa78
--- /dev/null
+++ b/doc/es/conf.py
@@ -0,0 +1,99 @@
+# -*- coding: utf-8 -*-
+#
+# Bazaar documentation build configuration file, created by
+# sphinx-quickstart on Tue Jul 21 17:04:52 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path = [os.path.abspath('../..')] + sys.path
+
+# Most of the configuration for Bazaar docs is defined here ...
+from bzrlib.doc_generate.conf import *
+
+
+## Configuration specific to this site ##
+
+# The locale code for this documentation set
+bzr_locale = 'es'
+
+# Translations & supporting helper function
+bzr_titles = {
+ u'Table of Contents (%s)': u'Contenidos (%s)',
+ u'Bazaar User Guide': u'Guia de Usuario',
+ u'Bazaar User Reference': None,
+ u'Bazaar Release Notes': None,
+ u'Bazaar Upgrade Guide': None,
+ u'Bazaar in five minutes': u'Bazaar en cinco minutos',
+ u'Bazaar Tutorial': None,
+ u'Using Bazaar With Launchpad': None,
+ u'Centralized Workflow Tutorial': None,
+ }
+def bzr_title(s):
+ return bzr_titles.get(s) or s
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+language = bzr_locale
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+html_short_title = bzr_title(u"Table of Contents (%s)") % (release,)
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {'index': 'index.html'}
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'bzr-%s' % (bzr_locale,)
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+bzr_documents = [
+ # Manuals
+ ('user-guide/index', 'bzr-%s-user-guide' % (bzr_locale,),
+ bzr_title(u'Bazaar User Guide'), bzr_team, 'manual'),
+ #('user-reference/bzr_man', 'bzr-%s-user-reference' % (bzr_locale,),
+ # bzr_title(u'Bazaar User Reference'), bzr_team, 'manual'),
+ #('release-notes/NEWS', 'bzr-%s-release-notes' % (bzr_locale,),
+ # bzr_title(u'Bazaar Release Notes'), bzr_team, 'manual'),
+ #('upgrade-guide/index', 'bzr-%s-upgrade-guide' % (bzr_locale,),
+ # bzr_title(u'Bazaar Upgrade Guide'), bzr_team, 'manual'),
+ # Tutorials
+ ('mini-tutorial/index', 'bzr-%s-tutorial-mini' % (bzr_locale,),
+ bzr_title(u'Bazaar in five minutes'), bzr_team, 'howto'),
+ #('tutorials/tutorial', 'bzr-%s-tutorial' % (bzr_locale,),
+ # bzr_title(u'Bazaar Tutorial'), bzr_team, 'howto'),
+ #('tutorials/using_bazaar_with_launchpad',
+ # 'bzr-%s-tutorial-with-launchpad' % (bzr_locale,),
+ # bzr_title(u'Using Bazaar With Launchpad'), bzr_team, 'howto'),
+ #('tutorials/centralized_workflow',
+ # 'bzr-%s-tutorial-centralized' % (bzr_locale,),
+ # bzr_title(u'Centralized Workflow Tutorial'), bzr_team, 'howto'),
+]
+
+latex_documents = [
+ (start, target+'.tex', title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+texinfo_documents = [
+ (start, target, title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+# List of documents that shouldn't be included in the build.
+unused_docs = [
+ # Subtopics that get included
+ 'upgrade-guide/overview',
+ 'upgrade-guide/data_migration',
+ 'upgrade-guide/tips_and_tricks',
+ 'user-guide/resolving_conflicts',
+ 'user-guide/version_info',
+ # Plain-style documentation generation stuff
+ 'user-guide/index-plain',
+]
+
diff --git a/doc/es/index.txt b/doc/es/index.txt
new file mode 100644
index 0000000..2d21d54
--- /dev/null
+++ b/doc/es/index.txt
@@ -0,0 +1,40 @@
+=================================
+Indice de Documentacion de Bazaar
+=================================
+
+Las ultimas versiones de estos documentos se encuentran disponibles
+en la pagina de Bazaar, http://doc.bazaar.canonical.com/en/.
+
+Documentacion Principal
+=======================
+
+.. toctree::
+ :maxdepth: 1
+
+ mini-tutorial/index
+ quick-reference/index
+ user-guide/index
+
+
+Otra Documentacion
+==================
+
+Mudandose a Bazaar (enlances web):
+
+* `Guias de Migracion <http://doc.bazaar.canonical.com/migration/en/>`_
+ - para equipos que mudan el historial de otros SCV
+
+* `Guias de Plugins <http://doc.bazaar.canonical.com/plugins/en/>`_
+
+Otros Documentos (enlances web):
+
+* `Glosario <http://wiki.bazaar.canonical.com/BzrGlossary>`_
+
+* `Preguntas Frecuentes <https://answers.launchpad.net/bzr>`_
+
+* `Referencia del API bzrlib <http://wiki.bazaar.canonical.com/BzrLib>`_
+
+Especificaciones tecnicas, planes a futuro y varias
+notas tecnicas varias en Ingles:
+
+* `Catalogo de Documentos para Desarrolladores <http://doc.bazaar.canonical.com/latest/developers/>`_
diff --git a/doc/es/mini-tutorial/index.txt b/doc/es/mini-tutorial/index.txt
new file mode 100644
index 0000000..35106bd
--- /dev/null
+++ b/doc/es/mini-tutorial/index.txt
@@ -0,0 +1,281 @@
+=======================
+Bazaar en cinco minutos
+=======================
+
+Introducción
+============
+
+Bazaar es un sistema de control de versiones distribuido que facilita que
+varias personas puedan trabajar de forma conjunta en proyectos de software.
+
+A lo largo de los próximos cinco minutos, aprenderá cómo poner sus archivos
+bajo control de versiones, como registrar cambios en ellos, examinar su
+trabajo, publicarlo y enviar su trabajo para que sea integrado en el trunk de
+un proyecto.
+
+Si prefiere una introducción más detallada, eche un vistazo a
+`Aprendiendo Más`_.
+
+
+Instalación
+===========
+
+Esta guía no describe cómo instalar Bazaar pero normalmente es muy
+sencillo. Puede encontrar intrucciones de instalación en:
+
+- **GNU/Linux:** Bazaar, probablemente, ya esté en su distribución GNU/Linux.
+- **Windows:** `instrucciones de instalación para Windows`_.
+- **Mac OS X:** `instrucciones de instalación para Mac OS X`_.
+
+Para otras plataformas y para instalar desde el código fuente, vea las
+páginas de Descarga_ e Instalación_.
+
+.. _instrucciones de instalación para Windows: http://wiki.bazaar.canonical.com/WindowsDownloads
+.. _instrucciones de instalación para Mac OS X: http://wiki.bazaar.canonical.com/MacOSXBundle
+.. _Descarga: http://wiki.bazaar.canonical.com/Download
+.. _Instalación: http://wiki.bazaar.canonical.com/InstallationFaq
+
+
+Preséntese
+==========
+
+Antes de empezar a trabajar, es conveniente que le diga a Bazaar quién es
+usted. De ese modo su trabajo será identificando correctamente en los logs
+de revisión.
+
+Utilice su nombre y dirección de email en lugar de John Doe, teclee::
+
+ $ bzr whoami "John Doe <john.doe@gmail.com>"
+
+Bazaar creará o modificará ahora un archivo de configuración, incluyendo su
+nombre y dirección de email.
+
+Ahora compruebe que su nombre y dirección de email se han registrado correctamente::
+
+ $ bzr whoami
+ John Doe <john.doe@gmail.com>
+
+
+Ponga archivos bajo control de versiones
+========================================
+
+Vamos a crear un directorio y algunos archivos para utilizar con Bazaar::
+
+ $ mkdir miproyecto
+ $ cd miproyecto
+ $ mkdir subdirectorio
+ $ touch test1.txt test2.txt test3.txt subdirectorio/test4.txt
+
+**Nota para usuarios de Windows:** utilice Windows Explorer para crear sus
+directorios, luego haga click derecho en dichos directorios y seleccione
+``Nuevo archivo`` para crear sus archivos.
+
+Ahora vamos a hacer que Bazaar se inicialize en el directorio de su proyecto::
+
+ $ bzr init
+
+Si parece que no ha ocurrido nada no se preocupe. Bazaar ha creado un
+branch_ dónde guardará sus archivos y su histórico de revisiones.
+
+.. _branch: http://wiki.bazaar.canonical.com/Branch
+
+El siguiente paso es decirle a Bazaar a que archivos desea seguirles la pista.
+Ejecutando ``bzr add`` agregará recursivamente todos los elementos dentro del
+proyecto::
+
+ $ bzr add
+ added subdirectorio
+ added test1.txt
+ added test2.txt
+ added test3.txt
+ added subdirectorio/test4.txt
+
+A continuación tome una instantánea de sus archivos agregándolos a su branch.
+Agregue un mensaje para explicar por qué hace el commit::
+
+ $ bzr commit -m "Importación inicial"
+
+Como Bazaar es un sistema de control de versiones distribuido, no necesita
+conectar con un servidor central para hacer el commit. Bazaar guarda su
+branch y todos sus commits dentro del directorio con el que está trabajando,
+busque el subdirectorio ``.bzr``.
+
+
+Haciendo cambios en sus archivos
+================================
+
+Vamos a cambiar un archivo e introduzcamos ese cambio en su branch.
+
+Edite ``test1.txt`` en su editor favorito y luego compruebe qué ha hecho::
+
+ $ bzr diff
+ === modified file 'test1.txt'
+ --- test1.txt 2007-10-08 17:56:14 +0000
+ +++ test1.txt 2007-10-08 17:46:22 +0000
+ @@ -0,0 +1,1 @@
+ +test test test
+
+Añada su trabajo al branch de Bazaar::
+
+ $ bzr commit -m "Añadida la primera línea de texto"
+ Committed revision 2.
+
+
+Viendo el log de revisiones
+===========================
+
+Puede ver el histórico de su branch navegando su log::
+
+ $ bzr log
+ ------------------------------------------------------------
+ revno: 2
+ committer: John Doe <john.doe@gmail.com>
+ branch nick: miproyecto
+ timestamp: Mon 2007-10-08 17:56:14 +0000
+ message:
+ Añadida la primera línea de texto
+ ------------------------------------------------------------
+ revno: 1
+ committer: John Doe <john.doe@gmail.com>
+ branch nick: miproyecto
+ timestamp: Mon 2006-10-08 17:46:22 +0000
+ message:
+ Importación inicial
+
+
+Publicando su branch con SFTP
+=============================
+
+Hay un par de maneras para publicar su branch. Si ya tiene un servidor
+SFTP o se siente cómodo configurando uno, puede publicar su branch con el.
+
+Sino salte a la siguiente sección para publicar con Launchpad_, un
+servicio de hosting gratuito para Bazaar.
+
+.. _Launchpad: https://launchpad.net/
+
+Vamos a suponer que desea publicar su branch en ``www.example.com/miproyecto``::
+
+ $ bzr push --create-prefix sftp://su.nombre@example.com/~/public_html/miproyecto
+ 2 revision(s) pushed.
+
+Bazaar creará un directorio ``miproyecto`` en el servidor remoto e
+introducirá su branch en él.
+
+Ahora cualquiera podrá crear su propia copia de su branch tecleando::
+
+ $ bzr branch http://www.example.com/miproyecto
+
+**Nota:** para utilizar SFTP deberá instalar ``paramiko`` y
+``pyCrypto``. Vea http://wiki.bazaar.canonical.com/InstallationFaq para más información.
+
+
+Publicando su branch con Launchpad
+==================================
+
+Launchpad es una suite de herramientas de desarrollo y hosting
+para proyectos de software libre. Puede utilizarlo para publicar su branch.
+
+Si no dispone de una cuenta de Launchpad, siga la `guia de registro de cuentas`_
+y `registre una clave SSH`_ en su nueva cuenta de Launchpad.
+
+.. _guia de registro de cuentas: https://help.launchpad.net/CreatingYourLaunchpadAccount
+.. _registre una clave SSH: https://launchpad.net/people/+me/+editsshkeys
+
+Cambie ``john.doe`` por su nombre de usuario de Launchpad, teclee::
+
+ $ bzr push bzr+ssh://john.doe@bazaar.launchpad.net/~john.doe/+junk/miproyecto
+
+**Nota:** ``+junk`` significa que este branch no está asociado con ningún proyecto
+concreto en Launchpad.
+
+Ahora cualquiera podrá crear su propia copia de su branch tecleando::
+
+ $ bzr branch http://bazaar.launchpad.net/~john.doe/+junk/miproyecto
+
+También puede ver información sobre su branch, histórico de revisiones
+incluido, en https://code.launchpad.net/people/+me/+junk/miproyecto
+
+
+Creando su propia copia de otro branch
+======================================
+
+Para trabajar con el código de otra persona, tendrá que hacer su propia
+copia de su branch. Vamos a coger un ejemplo real, la interfaz GTK de Bazaar::
+
+ $ bzr branch http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk bzr-gtk.john
+ Branched 292 revision(s).
+
+Bazaar descargará todos los archivos y el histórico de revisiones completo
+del trunk branch del proyecto bzr-gtk y creará una copia llamada
+bzr-gtk.john.
+
+Ahora dispone de su propia copia del branch y puede enviar cambios con
+o sin una conexión de red. Puede compartir su branch en cualquier momento
+publicándola y, si el equipo de bzr-gtk desea utilizar su trabajo, Bazaar
+les facilita integrar su branch dentro de su trunk branch.
+
+
+Actualizando su branch desde el branch principal
+================================================
+
+Mientras envía cambios a su branch, es probable que otras personas también
+sigan enviando código al branch principal.
+
+Para asegurarse de que su branch está al dia debería integrar los cambios
+desde el principal dentro de su branch personal::
+
+ $ bzr merge
+ Merging from saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
+ All changes applied successfully.
+
+Compruebe qué ha cambiado::
+
+ $ bzr diff
+
+Si está contento con los cambios puede añadirlos en su branch personal::
+
+ $ bzr commit -m "Integración desde el branch principal"
+ Committed revision 295.
+
+
+Integrando su trabajo en el branch principal
+============================================
+
+Después de haber trabajado en su branch personal de bzr-gtk puede que
+quiera enviar sus cambios de vuelta al proyecto. La manera más fácil
+es utilizando una instrucción merge.
+
+Una instrucción merge es una petición de lectura mecánica para
+llevar a cabo una integración concreta. Por lo general contiene un
+parche de vista previa de la integración y, o bien contiene las
+revisiones necesarias, o proporciona un branch donde pueden encontrarse.
+
+Sustituyendo ``mycode.patch``, cree su instrucción merge::
+
+ $ bzr send -o mycode.patch
+ Using saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
+
+Ahora puede enviar por email la instruccion merge al proyecto bzr-gtk
+quien, si así lo quieren, pueden utilizarla para integrar su trabajo
+dentro del branch principal.
+
+
+Aprendiendo más
+===============
+
+Puede encontrar más sobre Bazaar en la
+`Guía de Usuario de Bazaar <../user-guide/index.html>`_.
+
+Para aprender sobre Bazaar por línea de comandos::
+
+ $ bzr help
+
+Para aprender sobre comandos de Bazaar::
+
+ $ bzr help commands
+
+Para aprender acerca del tema o comando ''foo''::
+
+ $ bzr help foo
+
diff --git a/doc/es/quick-reference/index.txt b/doc/es/quick-reference/index.txt
new file mode 100644
index 0000000..5473593
--- /dev/null
+++ b/doc/es/quick-reference/index.txt
@@ -0,0 +1,6 @@
+Referencia Rapida
+=================
+
+* `PDF format <../_static/es/bzr-es-quick-reference.pdf>`_
+* `PNG format <../_static/es/bzr-es-quick-reference.png>`_
+* `SVG format <../_static/es/bzr-es-quick-reference.svg>`_
diff --git a/doc/es/user-guide/index-plain.txt b/doc/es/user-guide/index-plain.txt
new file mode 100644
index 0000000..e411965
--- /dev/null
+++ b/doc/es/user-guide/index-plain.txt
@@ -0,0 +1,114 @@
+##########################
+Guia de Usuarios de Bazaar
+##########################
+
+.. Files are currently links but will become includes once the
+.. content makes more sense as a whole.
+.. Please mark sections in linked/included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+
+Introducción
+############
+
+.. include later - introducing_bazaar.txt
+.. include later - core_concepts.txt
+.. include later - bazaar_workflows.txt
+
+
+Empezando
+#########
+
+.. include later - installing_bazaar.txt
+.. include later - entering_commands.txt
+.. include later - revnos.txt
+.. include later - getting_help.txt
+.. include later - configuring_bazaar.txt
+.. include later - using_aliases.txt
+.. include later - plugins.txt
+
+
+Control de Versionamiento Personal
+##################################
+
+.. include later - solo_intro.txt
+.. include later - starting_a_project.txt
+.. include later - controlling_registration.txt
+.. include later - reviewing_changes.txt
+.. include later - recording_changes.txt
+.. include later - browsing_history.txt
+.. include later - releasing_a_project.txt
+.. include later - undoing_mistakes.txt
+
+
+Compartiendo con tus pares
+##########################
+
+.. include later - partner_intro.txt
+.. include later - branching_a_project.txt
+.. include later - merging_changes.txt
+.. include later - resolving_conflicts.txt
+.. include later - annotating_changes.txt
+
+
+Colaboración en equipo, modo centralizado
+#########################################
+
+.. include later - central_intro.txt
+.. include later - publishing_a_branch.txt
+.. include later - using_checkouts.txt
+.. include later - working_offline_central.txt
+.. include later - reusing_a_checkout.txt
+
+
+Colaboracion en equipo, modo distribuido
+########################################
+
+.. include later - distributed_intro.txt
+.. include later - organizing_branches.txt
+.. include later - using_gatekeepers.txt
+.. include later - sending_changes.txt
+
+
+Un tour breve de los plugins mas populares
+##########################################
+
+.. include later - part2_intro.txt
+.. include later - bzrtools_plugin.txt
+.. include later - svn_plugin.txt
+.. include later looms_plugin.txt
+
+
+Integrando Bazaar en tu entorno
+###############################
+
+.. include later - web_browsing.txt
+.. include later - file_explorers.txt
+.. include later - desktop_integration.txt
+.. include later - editors_and_ides.txt
+.. include later - email.txt
+.. include later - bug_trackers.txt
+
+
+Temas varios
+############
+
+.. include later - adv_merging.txt
+.. include later - server.txt
+.. include later - hooks.txt
+.. include:: version_info.txt
+
+
+Apéndice
+########
+
+.. include later - specifying_revisions.txt
+.. include later - shared_repository_layouts.txt
+.. include later - setting_up_email.txt
+.. include later - http_smart_server.txt
+.. include later - writing_a_plugin.txt
+
+.. |--| unicode:: U+2014
diff --git a/doc/es/user-guide/index.txt b/doc/es/user-guide/index.txt
new file mode 100644
index 0000000..e411965
--- /dev/null
+++ b/doc/es/user-guide/index.txt
@@ -0,0 +1,114 @@
+##########################
+Guia de Usuarios de Bazaar
+##########################
+
+.. Files are currently links but will become includes once the
+.. content makes more sense as a whole.
+.. Please mark sections in linked/included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+
+Introducción
+############
+
+.. include later - introducing_bazaar.txt
+.. include later - core_concepts.txt
+.. include later - bazaar_workflows.txt
+
+
+Empezando
+#########
+
+.. include later - installing_bazaar.txt
+.. include later - entering_commands.txt
+.. include later - revnos.txt
+.. include later - getting_help.txt
+.. include later - configuring_bazaar.txt
+.. include later - using_aliases.txt
+.. include later - plugins.txt
+
+
+Control de Versionamiento Personal
+##################################
+
+.. include later - solo_intro.txt
+.. include later - starting_a_project.txt
+.. include later - controlling_registration.txt
+.. include later - reviewing_changes.txt
+.. include later - recording_changes.txt
+.. include later - browsing_history.txt
+.. include later - releasing_a_project.txt
+.. include later - undoing_mistakes.txt
+
+
+Compartiendo con tus pares
+##########################
+
+.. include later - partner_intro.txt
+.. include later - branching_a_project.txt
+.. include later - merging_changes.txt
+.. include later - resolving_conflicts.txt
+.. include later - annotating_changes.txt
+
+
+Colaboración en equipo, modo centralizado
+#########################################
+
+.. include later - central_intro.txt
+.. include later - publishing_a_branch.txt
+.. include later - using_checkouts.txt
+.. include later - working_offline_central.txt
+.. include later - reusing_a_checkout.txt
+
+
+Colaboracion en equipo, modo distribuido
+########################################
+
+.. include later - distributed_intro.txt
+.. include later - organizing_branches.txt
+.. include later - using_gatekeepers.txt
+.. include later - sending_changes.txt
+
+
+Un tour breve de los plugins mas populares
+##########################################
+
+.. include later - part2_intro.txt
+.. include later - bzrtools_plugin.txt
+.. include later - svn_plugin.txt
+.. include later looms_plugin.txt
+
+
+Integrando Bazaar en tu entorno
+###############################
+
+.. include later - web_browsing.txt
+.. include later - file_explorers.txt
+.. include later - desktop_integration.txt
+.. include later - editors_and_ides.txt
+.. include later - email.txt
+.. include later - bug_trackers.txt
+
+
+Temas varios
+############
+
+.. include later - adv_merging.txt
+.. include later - server.txt
+.. include later - hooks.txt
+.. include:: version_info.txt
+
+
+Apéndice
+########
+
+.. include later - specifying_revisions.txt
+.. include later - shared_repository_layouts.txt
+.. include later - setting_up_email.txt
+.. include later - http_smart_server.txt
+.. include later - writing_a_plugin.txt
+
+.. |--| unicode:: U+2014
diff --git a/doc/es/user-guide/version_info.txt b/doc/es/user-guide/version_info.txt
new file mode 100644
index 0000000..d7fab0c
--- /dev/null
+++ b/doc/es/user-guide/version_info.txt
@@ -0,0 +1,53 @@
+===========================
+Usando ``bzr version-info``
+===========================
+
+Repaso General
+==============
+
+Este documento describe las formas de usar ``bzr version-info`` como
+parte del proceso de embeber la informacion de vesion a un proyecto.
+
+
+Projecto Python
+===============
+
+TODO: Figure out how to attach into ``setup.py``
+
+Si usa un archivo Makefile para construir su proyecto, puede generar un
+archivo on la informacion de version tan simple como::
+
+ library/_version.py:
+ bzr version-info --format=python > library/_version.py
+
+Eso genera un archivo que contiene 3 diccionarios:
+
+ * `version_info`: Un diccionario conteniendo informacion basica sobre el
+ estado actual
+
+ * `revisions`: Un diccionario listando todas las revisiones en
+ el historial del tree, junto con los tiempos y los mensajes de
+ los commits. Esto por defecto esta en blanco salvi que use ``--all``
+ o `--include-history`` es provisto. Esto es util si quiere seguir
+ que bugs arregla el lanzamiento de esa version. Para muchos proyectos
+ es mas informacion de la que se va a necesitar.
+
+ * `file_revisions`: Un diccionario listando la revision que modifico
+ por ultima vez todos los archivos del proyecto. Esto puede ser usado
+ similarmente a como se usan las palabras claves ``$Id$`` en los
+ archivos controlados en CVS. La ultima fecha de modificacion puede
+ ser determinada mirando en el mapa de ``revisions``. Esto tambien
+ esta vacio por defecto, y habilitado solo por ``--all`` o
+ ``--include-file-revisions``.
+
+
+Check Clean
+===========
+
+La mayoria de la informacion sobre el contenido del proyecto puede
+ser determinada a muy bajo costo con solo leer las entradas de revisiones.
+Sin embargo, puede ser util si el working tree fue actualizado completamente
+cuando fue empaquetado, o si hubo alguna modificacion local. Al proveer
+``--all`` o ``--check-clean``, ``bzr`` va a inspeccionar el working tree,
+y definir el ``clean`` flag en ``version_info``, al igual que definir
+entradas en ``file_revisions`` como ``modified`` donde es apropiado.
diff --git a/doc/index.es.txt b/doc/index.es.txt
new file mode 100644
index 0000000..938552b
--- /dev/null
+++ b/doc/index.es.txt
@@ -0,0 +1,46 @@
+==================================
+Indice de Documentacion de Bazaar
+==================================
+
+Las ultimas versiones de estos documentos se encuentran disponibles
+en la pagina de Bazaar, http://doc.bazaar.canonical.com/.
+
+Documentacion Principal
+=======================
+
+* `Mini Tutorial <es/mini-tutorial/index.html>`_
+
+* `Referencia Rapida <es/_static/es/bzr-es-quick-reference.svg>`_
+
+* `Guia de Usuario <es/user-guide/index-plain.html>`_
+
+* `Referencia <en/user-reference/bzr_man.html>`_
+
+* `Notas sobre la Version <en/release-notes/NEWS.html>`_
+
+* `Guia del Desarrollador <developers/HACKING.html>`_
+
+
+Otra Documentacion
+===================
+
+Mudandose a Bazaar (enlances web):
+
+* `Guias de Mudanzas <http://wiki.bazaar.canonical.com/BzrSwitching>`_
+ - para los usuarios que se mudan de otros SCV
+
+* `Guias de Migracion <http://wiki.bazaar.canonical.com/BzrMigration>`_
+ - para equipos que mudan el historial de otros SCV
+
+Otros Documentos (enlances web):
+
+* `Glosario <http://wiki.bazaar.canonical.com/BzrGlossary>`_
+
+* `Preguntas Frecuentes <http://wiki.bazaar.canonical.com/FAQ>`_
+
+* `Referencia del API bzrlib <http://wiki.bazaar.canonical.com/BzrLib>`_
+
+Especificaciones tecnicas, planes a futuro y varias
+notas tecnicas varias en Ingles:
+
+* `Catalogo de Documentos para Desarrolladores <developers/index.html>`_
diff --git a/doc/index.ja.txt b/doc/index.ja.txt
new file mode 100644
index 0000000..a013381
--- /dev/null
+++ b/doc/index.ja.txt
@@ -0,0 +1,85 @@
+===========================
+Bazaarのメインドキュメント
+===========================
+
+これらのドキュメントの最新版はBazaarのドキュメントのサイト、 http://doc.bazaar.canonical.com/ から入手可能で、
+詳しい情報は http://wiki.bazaar.canonical.com/Documentation のページからリンクされています。
+
+
+コアドキュメント
+================
+
+* `ユーザーガイド <ja/user-guide/index.html>`_
+
+* `ユーザーリファレンス <ja/user-reference/bzr_man.html>`_
+
+* `クィックスタートカード(PNG) <http://gigo-ice.org/scm/bazaar/wiki/bzr-quickref.ja.png>`_
+ `(PDF) <http://gigo-ice.org/scm/bazaar/wiki/bzr-quickref.ja.pdf>`_
+
+* `リリースノート(英語) <en/release-notes/NEWS.html>`_
+
+* `2.0 Upgrade Guide (英語) <en/upgrade-guide/index.html>`_
+
+チュートリアル
+===============
+
+* `5分でBazaar <ja/mini-tutorial/index.html>`_
+
+* `A longer tutorial (英語) <en/tutorials/tutorial.html>`_
+
+* `Using Bazaar with Launchpad (英語) <en/tutorials/using_bazaar_with_launchpad.html>`_
+
+* `Centralized workflow (英語) <en/tutorials/centralized_workflow.html>`_
+
+
+Developer Documentation
+=======================
+
+* `Developer Document Catalog <developers/index-plain.html>`_ |--| for developers
+ of Bazaar and plugins
+
+
+ウェブリンク
+=============
+
+* `切り替えガイド <http://wiki.bazaar.canonical.com/BzrSwitching>`_
+ |--| 別のVCSツールから移ってきたユーザー用
+
+* `移行ガイド <http://wiki.bazaar.canonical.com/BzrMigration>`_
+ |--| 別のVCSツールから履歴を移行するチーム用
+
+* `用語 <http://wiki.bazaar.canonical.com/BzrGlossary>`_
+
+* `よく聞かれる質問 <http://wiki.bazaar.canonical.com/FAQ>`_
+
+
+TortoiseBzrをインストールするには?
+===================================
+
+https://launchpad.net/bzr/+download からbzr-setup-x.xxx.exeを入手し、
+ファイルをダブルクリックをしてインストールウィザードを起動させます。
+その後の作業はインストールウィザードに従います。
+インストールウィザードが終了した後で再起動します。
+
+最新バージョンでも正常に動作しないことがあるので、
+その場合は古いバージョンをインストールします。
+2009年1月時点で筆者はbzr-setup-1.9.exeの基本的な動作を確認しています。
+
+もしPythonインタープリタにbzrをインストールした場合、インストールしたディレクトリによって
+bzr.exe(デフォルトでは `C:\Program Files\Bazaar` )よりもbzr.bat(`C:\PythonXX\Scripts`)が
+優先されるので、コマンドプロンプトでbzrと入力したときにbzr.exeが実行されるようにするには、
+bzr.batをbzr.txtなどにリネームします。
+
+
+Other Languages
+===============
+
+* `Spanish Documentation <index.es.html>`_
+* `Russian Documentation <index.ru.html>`_ |--| документация на русском
+* `Japanese Documentation <index.ja.html>`_ |--| 日本語ドキュメント
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/index.ru.txt b/doc/index.ru.txt
new file mode 100644
index 0000000..c4585f9
--- /dev/null
+++ b/doc/index.ru.txt
@@ -0,0 +1,63 @@
+=================================
+Главный каталог документов Bazaar
+=================================
+
+Последняя версия этих документов доступа со страницы документации
+на сайте Bazaar, <http://doc.bazaar.canonical.com/>. Еще больше информации
+можно получить по адресу <http://wiki.bazaar.canonical.com/Documentation>.
+
+Основная документация
+=====================
+
+* `Руководство пользователя <ru/user-guide/index-plain.html>`_
+
+* `Справочник пользователя <en/user-reference/bzr_man.html>`_ (англ.)
+
+* `Карточка быстрого старта <ru/_static/ru/bzr-ru-quick-reference.svg>`_
+ (`PDF <ru/_static/ru/bzr-ru-quick-reference.pdf>`_,
+ `PNG <ru/_static/ru/bzr-ru-quick-reference.png>`_)
+
+* `Список изменений <en/release-notes/NEWS.html>`_ (англ.)
+
+* `Каталог информации для разработчиков <developers/index-plain.html>`_ (англ.) |--|
+ для разработчиков Bazaar и плагинов
+
+Учебники
+========
+
+* `Базар за пять минут <ru/mini-tutorial/index.html>`_
+
+* `Большой учебник <ru/tutorials/tutorial.html>`_
+
+* `Использование Bazaar с Launchpad
+ <ru/tutorials/using_bazaar_with_launchpad.html>`_
+
+* `Работа в централизованном стиле
+ <ru/tutorials/centralized_workflow.html>`_
+
+Ссылки в сети
+=============
+
+* `Руководства по переходу <http://wiki.bazaar.canonical.com/BzrSwitching>`_
+ |--| для пользователей переходящих с других систем контроля версий
+
+* `Руководство по миграции <http://wiki.bazaar.canonical.com/BzrMigration>`_
+ |--| для команд переносящих историю с других систем контроля версий
+
+* `Словарь терминов <http://wiki.bazaar.canonical.com/BzrGlossary>`_ (англ.),
+ см. также `русскую версию`__
+
+__ http://groups.google.com/group/ru_bzr/web/%D0%B3%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
+
+* `Часто задаваемые вопросы <http://wiki.bazaar.canonical.com/FAQ>`_ (англ.)
+
+Другие языки
+============
+
+* `Документация на английском <index.html>`_ |--| English Documentation
+* `Документация на испанском <index.es.html>`_
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/index.txt b/doc/index.txt
new file mode 100644
index 0000000..e234017
--- /dev/null
+++ b/doc/index.txt
@@ -0,0 +1,67 @@
+============================
+Bazaar Main Document Catalog
+============================
+
+The latest version of these documents are available from Bazaar's
+documentation site, <http://doc.bazaar.canonical.com/>, and more documentation
+may be linked from <http://wiki.bazaar.canonical.com/Documentation>.
+
+Core Documentation
+==================
+
+* `User Guide <en/user-guide/index-plain.html>`_
+
+* `User Reference <en/user-reference/bzr_man.html>`_
+
+* `Quick Start Card <en/_static/en/bzr-en-quick-reference.svg>`_
+ (`PDF <en/_static/en/bzr-en-quick-reference.pdf>`_,
+ `PNG <en/_static/en/bzr-en-quick-reference.png>`_)
+
+* `Release Notes <en/release-notes/NEWS.html>`_
+
+* `2.0 Upgrade Guide <en/upgrade-guide/index.html>`_
+
+
+Tutorials
+=========
+
+* `Bazaar in five minutes <en/mini-tutorial/index.html>`_
+
+* `A longer tutorial <en/tutorials/tutorial.html>`_
+
+* `Using Bazaar with Launchpad <en/tutorials/using_bazaar_with_launchpad.html>`_
+
+* `Centralized workflow <en/tutorials/centralized_workflow.html>`_
+
+
+Developer Documentation
+=======================
+
+* `Developer Document Catalog <developers/index-plain.html>`_ |--| for developers
+ of Bazaar and plugins
+
+Web links
+=========
+
+* `Switching Guides <http://wiki.bazaar.canonical.com/BzrSwitching>`_
+ |--| for users moving from another VCS tool
+
+* `Migration Guide <http://wiki.bazaar.canonical.com/BzrMigration>`_
+ |--| for teams migrating history from another VCS tool
+
+* `Glossary <http://wiki.bazaar.canonical.com/BzrGlossary>`_
+
+* `Frequently Asked Questions <http://wiki.bazaar.canonical.com/FAQ>`_
+
+
+Other Languages
+===============
+
+* `Spanish Documentation <index.es.html>`_
+* `Russian Documentation <index.ru.html>`_ |--| документация на русском
+* `Japanese Documentation <index.ja.html>`_ |--| 日本語のドキュメント
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/ja/_static/bzr icon 16.png b/doc/ja/_static/bzr icon 16.png
new file mode 100644
index 0000000..0c8d454
--- /dev/null
+++ b/doc/ja/_static/bzr icon 16.png
Binary files differ
diff --git a/doc/ja/_static/bzr.ico b/doc/ja/_static/bzr.ico
new file mode 100644
index 0000000..a49eb7e
--- /dev/null
+++ b/doc/ja/_static/bzr.ico
Binary files differ
diff --git a/doc/ja/conf.py b/doc/ja/conf.py
new file mode 100644
index 0000000..5357bd4
--- /dev/null
+++ b/doc/ja/conf.py
@@ -0,0 +1,103 @@
+# -*- coding: utf-8 -*-
+#
+# Bazaar documentation build configuration file, created by
+# sphinx-quickstart on Tue Jul 21 17:04:52 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path = [os.path.abspath('../..')] + sys.path
+
+# Most of the configuration for Bazaar docs is defined here ...
+from bzrlib.doc_generate.conf import *
+
+
+## Configuration specific to this site ##
+
+# The locale code for this documentation set
+bzr_locale = 'ja'
+
+# Translations & supporting helper function
+bzr_titles = {
+ u'Table of Contents (%s)': u'目次 (%s)',
+ u'Bazaar User Guide': u'ユーザーガイド',
+ u'Bazaar User Reference': u'ユーザーリファレンス',
+ u'Bazaar Release Notes': u'リリースノート',
+ u'Bazaar Upgrade Guide': u'アップグレードガイド',
+ u'Bazaar in five minutes': u'5分でBazaar',
+ u'Bazaar Tutorial': u'チュートリアル',
+ u'Using Bazaar With Launchpad': None,
+ u'Centralized Workflow Tutorial': None,
+ }
+def bzr_title(s):
+ return bzr_titles.get(s) or s
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+language = bzr_locale
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+html_short_title = bzr_title(u"Table of Contents (%s)") % (release,)
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+# html_additional_pages = {'index': 'index.html'}
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'bzr-%s' % (bzr_locale,)
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+bzr_documents = [
+ # Manuals
+ ('user-guide/index', 'bzr-%s-user-guide' % (bzr_locale,),
+ bzr_title(u'Bazaar User Guide'), bzr_team, 'manual'),
+ ('user-reference/bzr_man', 'bzr-%s-user-reference' % (bzr_locale,),
+ bzr_title(u'Bazaar User Reference'), bzr_team, 'manual'),
+ #('release-notes/NEWS', 'bzr-%s-release-notes' % (bzr_locale,),
+ # bzr_title(u'Bazaar Release Notes'), bzr_team, 'manual'),
+ #('upgrade-guide/index', 'bzr-%s-upgrade-guide' % (bzr_locale,),
+ # bzr_title(u'Bazaar Upgrade Guide'), bzr_team, 'manual'),
+ # Tutorials
+ ('mini-tutorial/index', 'bzr-%s-tutorial-mini' % (bzr_locale,),
+ bzr_title(u'Bazaar in five minutes'), bzr_team, 'howto'),
+ #('tutorials/tutorial', 'bzr-%s-tutorial' % (bzr_locale,),
+ # bzr_title(u'Bazaar Tutorial'), bzr_team, 'howto'),
+ #('tutorials/using_bazaar_with_launchpad',
+ # 'bzr-%s-tutorial-with-launchpad' % (bzr_locale,),
+ # bzr_title(u'Using Bazaar With Launchpad'), bzr_team, 'howto'),
+ #('tutorials/centralized_workflow',
+ # 'bzr-%s-tutorial-centralized' % (bzr_locale,),
+ # bzr_title(u'Centralized Workflow Tutorial'), bzr_team, 'howto'),
+]
+
+latex_documents = [
+ (start, target+'.tex', title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+texinfo_documents = [
+ (start, target, title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+# List of documents that shouldn't be included in the build.
+unused_docs = [
+ # Subtopics that get included
+ 'upgrade-guide/overview',
+ 'upgrade-guide/data_migration',
+ 'upgrade-guide/tips_and_tricks',
+ #'user-guide/resolving_conflicts',
+ #'user-guide/version_info',
+ # Plain-style documentation generation stuff
+ 'release-notes/NEWS',
+ 'user-reference/bzr_man',
+ 'user-guide/index-plain',
+ # Miscellaneous
+ 'user-reference/readme',
+]
+
diff --git a/doc/ja/index.txt b/doc/ja/index.txt
new file mode 100644
index 0000000..1d773c2
--- /dev/null
+++ b/doc/ja/index.txt
@@ -0,0 +1,58 @@
+===========================
+Bazaarのメインドキュメント
+===========================
+
+これらのドキュメントの最新版はBazaarのドキュメントのサイト、
+http://doc.bazaar.canonical.com/en/ から入手可能で、
+詳しい情報は http://wiki.bazaar.canonical.com/Documentation
+のページからリンクされています。
+
+
+目次
+=====
+
+.. toctree::
+ :maxdepth: 1
+
+ tutorials/index
+ user-guide/index
+ upgrade-guide/index
+ user-reference/index
+
+.. no translated documents
+ quick-reference/index
+ admin-guide/index
+
+ウェブリンク
+=============
+
+* `切り替えガイド <http://wiki.bazaar.canonical.com/BzrSwitching>`_
+ |--| 別のVCSツールから移ってきたユーザー用
+
+* `移行ガイド <http://wiki.bazaar.canonical.com/BzrMigration>`_
+ |--| 別のVCSツールから履歴を移行するチーム用
+
+* `用語 <http://wiki.bazaar.canonical.com/BzrGlossary>`_
+
+* `よく聞かれる質問 <http://wiki.bazaar.canonical.com/FAQ>`_
+
+
+TortoiseBzrをインストールするには?
+===================================
+
+https://launchpad.net/bzr/+download からbzr-setup-x.xxx.exeを入手し、
+ファイルをダブルクリックをしてインストールウィザードを起動させます。
+その後の作業はインストールウィザードに従います。
+インストールウィザードが終了した後で再起動します。
+
+もしPythonインタープリタにbzrをインストールした場合、インストールしたディレクトリによって
+bzr.exe(デフォルトでは ``C:\Program Files\Bazaar`` )よりもbzr.bat(``C:\PythonXX\Scripts``)が
+優先されるので、コマンドプロンプトでbzrと入力したときにbzr.exeが実行されるようにするには、
+bzr.batをbzr.txtなどにリネームします。
+
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/ja/mini-tutorial/index.txt b/doc/ja/mini-tutorial/index.txt
new file mode 100644
index 0000000..ccb971f
--- /dev/null
+++ b/doc/ja/mini-tutorial/index.txt
@@ -0,0 +1,272 @@
+=================
+5分でわかるBazaar
+=================
+
+.. _introduction:
+
+イントロダクション
+===================
+
+Bazaarは分散型バージョン管理システムで、ソフトウェアプロジェクトの
+共同作業を楽にしてくれます。
+
+これから5分ほどで、ファイルをバージョン管理下に置き、変更を記録して、
+作業内容を確認し、公開して作業内容をマージしてもらうためにプロジェクトの
+trunk に送る方法などを学びます。
+
+詳細な紹介内容を望むのであれば、 `さらに学ぶ`_ をご覧ください。
+
+
+インストール方法
+=================
+
+このガイドではBazaarをインストールする方法を説明しませんが、通常はとても簡単です。
+インストール方法の手引きは次の通りです:
+
+- **GNU/Linux:** おそらくBazaarはあなたのGNU/Linuxディストリビューションに含まれています。
+- **Windows:** `Windowsのためのインストールの手引き`_.
+- **Mac OS X:** `Mac OS Xのためのインストールの手引き`_.
+
+別のプラットフォームとソースコードからインストールする方法に関しては、 ダウンロード_
+と インストール方法_ のページを参照してください。
+
+.. _Windowsのためのインストールの手引き: http://wiki.bazaar.canonical.com/WindowsDownloads
+.. _Mac OS Xのためのインストールの手引き: http://wiki.bazaar.canonical.com/MacOSXBundle
+.. _ダウンロード: http://wiki.bazaar.canonical.com/Download
+.. _インストール方法: http://wiki.bazaar.canonical.com/InstallationFaq
+
+
+まずは自己紹介
+=================
+
+作業にとりかかる前に、まずあなたが誰なのかをBazaarに教えてあげましょう。
+そうすることで、履歴の中からあなたの作業を正確に識別することができます。
+
+次のように入力してください(もちろん、あなたの名前とEメールアドレスで)::
+
+ $ bzr whoami "John Doe <john.doe@gmail.com>"
+
+こうするとBazaarは、あなたの名前やEメールアドレスが入った設定ファイルを作成\
+もしくは修正します。
+
+名前とEメールアドレスが正しく登録されているか確認しましょう ::
+
+ $ bzr whoami
+ John Doe <john.doe@gmail.com>
+
+
+ファイルをバージョン管理する
+=============================
+
+Bazaarで扱うディレクトリといくつかのファイルを作りましょう::
+
+ $ mkdir myproject
+ $ cd myproject
+ $ mkdir subdirectory
+ $ touch test1.txt test2.txt test3.txt subdirectory/test4.txt
+
+**Windowsユーザーのための注意:** Windows Explorerを使ってディレクトリを作成し、\
+そのディレクトリの中で右クリックをして ``新規作成`` を選択し、ファイルを作成します。
+
+Bazaarにあなたのプロジェクトディレクトリを初期化させましょう::
+
+ $ bzr init
+
+何も起きていないように見えても心配しないでください。
+Bazaarはファイルとリビジョンの履歴を保存する branch_ を作りました。
+
+.. _branch: http://wiki.bazaar.canonical.com/Branch
+
+次のステップはBazaarに管理して欲しいファイルを教えることです。
+``bzr add`` を実行するとすべてのディレクトリとファイルがプロジェクトに\
+再帰的に追加されます。 ::
+
+ $ bzr add
+ added subdirectory
+ added test1.txt
+ added test2.txt
+ added test3.txt
+ added subdirectory/test4.txt
+
+次に、これらをブランチにコミットしてスナップショットをとります。
+コミットを行った理由を説明するメッセージを追加します。 ::
+
+ $ bzr commit -m "Initial import"
+
+Bazaarは分散型バージョン管理システムなので、コミットするために\
+サーバーに接続する必要はありません。
+代わりに、Bazaarはブランチとすべてのコミットをあなたが作業している\
+ディレクトリ内部に ``.bzr`` というサブディレクトリを作ってそこに
+保存します。
+
+
+ファイルを変更する
+===================
+
+ファイルを変更してブランチにその変更をコミットしてみましょう。
+
+好きなエディタで ``test1.txt`` を編集し、何を行ったのかを確認します。 ::
+
+ $ bzr diff
+ === modified file 'test1.txt'
+ --- test1.txt 2007-10-08 17:56:14 +0000
+ +++ test1.txt 2007-10-08 17:46:22 +0000
+ @@ -0,0 +1,1 @@
+ +test test test
+
+作業をBazaarのブランチにコミットします::
+
+ $ bzr commit -m "Added first line of text"
+ Committed revision 2.
+
+
+リビジョンのログを眺める
+=========================
+
+ログを閲覧することでブランチの履歴を調べることができます。 ::
+
+ $ bzr log
+ ------------------------------------------------------------
+ revno: 2
+ committer: John Doe <john.doe@gmail.com>
+ branch nick: myproject
+ timestamp: Mon 2007-10-08 17:56:14 +0000
+ message:
+ Added first line of text
+ ------------------------------------------------------------
+ revno: 1
+ committer: John Doe <john.doe@gmail.com>
+ branch nick: myproject
+ timestamp: Mon 2006-10-08 17:46:22 +0000
+ message:
+ Initial import
+
+
+ブランチを Launchpad で公開する
+===================================
+
+Launchpad はソフトウェアプロジェクトの開発と運営のためのツールをまとめた
+サイトです。自分のブランチを公開するために Launchpad を利用することができます。
+(もちろん、自分のサーバーや他のホスティングサービス上で公開することもできます)
+
+まだ Launchpad のアカウントを持っていないのであれば、 `account signup guide`_
+に従ってアカウントを作成し、 `SSH 鍵を登録`_ してください。
+
+.. _account signup guide: https://help.launchpad.net/CreatingYourLaunchpadAccount
+.. _SSH 鍵を登録: https://launchpad.net/people/+me/+editsshkeys
+
+次のように、 (``john.doe`` は自分のアカウントのユーザー名に置き換えて)
+タイプしてください。 [#]_ ::
+
+ $ bzr push lp:~john.doe/+junk/myproject
+
+.. [#] ``lp:`` という URL スキーマは bzr 0.92 以降でサポートされています。
+
+**注意**: ``+junk`` の部分は、このブランチが Launchpad 上の特定のプロジェクトに
+属していないことを意味しています。
+
+これで、誰でもあなたのブランチのコピーを、次のようなコマンドで入手できるようになりました。 ::
+
+ $ bzr branch lp:~john.doe/+junk/myproject
+
+ブランチの情報を、履歴も含めて
+https://code.launchpad.net/people/+me/+junk/myproject
+から閲覧することができます。
+
+
+別のブランチから自分用のコピーを作る
+=====================================
+
+他人のコードに取り組むために、ブランチのコピーを作ることができます。
+実際の世界の例として、BazaarのGTKインターフェイスを見てみましょう::
+
+ $ bzr branch lp:~bzr/bzr-gtk/trunk bzr-gtk.john
+ Branched 292 revision(s).
+
+Bazaarはbzr-gtkのtrunkブランチからすべてのファイルをダウンロードして
+リビジョンの履歴をそろえ、bzr-gtk.johnというコピーを作ります。
+
+これで、ブランチのコピーを手に入れたのでネットの接続のあるなしに
+関わらず変更をコミットできます。
+ブランチはいつでも公開することで共有でき、bzr-gtkチームがあなたの作品を
+使いたいと思ったときにBazaarは彼らがあなたのブランチから彼らのブランチに
+マージし直す作業を簡単にしてくれます。
+
+
+メインのブランチから自分のブランチを更新する
+=============================================
+
+変更を自分のブランチにコミットしている間に、他の人がコードを元のブランチに\
+コミットしているということもよくあります。
+
+自分のブランチを最新に維持するには、親ブランチから自分のブランチへと変更を\
+マージします::
+
+ $ bzr merge
+ Merging from saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
+ All changes applied successfully.
+
+何が変更されたのか確認します::
+
+ $ bzr diff
+
+変更に満足したら、それらを自分のブランチにコミットします::
+
+ $ bzr commit -m "Merge from main branch"
+ Committed revision 295.
+
+
+作業を親のブランチにマージする
+==============================
+
+bzr-gtkの個人ブランチに取り組んだ後で、あなたの変更を上流のプロジェクトに\
+戻したいことがあるかもしれません。
+最も簡単な方法はマージディレクティブを使うことです。
+
+マージディレクティブ(merge directive)とは、コンピュータに特定のマージを実行\
+させるためのリクエストです。
+マージディレクティブは大抵、マージをレビューするためのパッチと、マージを実行する\
+のに必要となるリビジョン、もしくはリビジョンを取得できるブランチを含みます。
+
+次のコマンドの ``mycode.patch`` を適当な名前に書き換えて、マージのディレクティブを作ります::
+
+ $ bzr send -o mycode.patch
+ Using saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
+
+これでbzr-gtkのプロジェクトにマージディレクティブをEメールで送ることが可能に\
+なりました。彼らが納得すれば、親ブランチにマージすることができます。
+
+
+さらに学ぶ
+==========
+
+Bazaarに関する詳細な内容は `Bazaarのユーザーガイド <../user-guide/index.html>`_ で調べることができます。
+
+コマンドラインでBazaarを学ぶには::
+
+ $ bzr help
+
+Bazaarのコマンドを学ぶには::
+
+ $ bzr help commands
+
+''foo'' トピックもしくはコマンドを学ぶには::
+
+ $ bzr help foo
+
+
+Licence
+=============
+
+Copyright 2007-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
+
+
+日本語訳について
+-----------------
+この日本語訳は、 `Bazaar-jaグループ <https://groups.google.com/group/bazaar-ja>`_
+がメンテナンスしています。
+
+日本語訳に着いて間違いや質問等ありましたらこちらへお願いします。
diff --git a/doc/ja/tutorials/centralized_workflow.txt b/doc/ja/tutorials/centralized_workflow.txt
new file mode 100644
index 0000000..389defe
--- /dev/null
+++ b/doc/ja/tutorials/centralized_workflow.txt
@@ -0,0 +1,283 @@
+========================================
+集中型ワークフローのチュートリアル
+========================================
+
+
+概要
+====
+
+この文書では、 Bazaar_ を使用することで実現可能なワークフローについて説明します。
+つまり、分散バージョンコントロールシステムである Bazaar_ を、集中型のやり方で使用するためのワークフローです。
+Bazaar_ は、非常にフレキシブルに設計されており、完全な分散型からほとんど集中型のワークフローまで、\
+いくつかの異なるワークフローを受け入れることができます。
+このワークフローは、初めてのユーザでも簡単に Bazaar_ を使いこなすことができ、\
+分散型と集中型のオペレーションを組み合わせた業務にも対応できるようになっています。
+
+基本的に、この文書はCVSや Subversion のような集中型バージョンコントロールシステムの経験があるユーザ向けに書かれています。
+これらの環境では、一般的に、コードベースをホストする単一の中央サーバが存在し、複数の人々がこのコードベース上で作業して、\
+お互いの作業の同期をとることになります。
+また、このワークフローは、一人の開発者が複数のマシーン上で作業をする場合にも適用できます。
+
+.. _Bazaar: http://bazaar.canonical.com
+
+
+初期セットアップ
+================
+
+Bazaar_ がうまく動くようにするための、まあまあ簡単なセットアップ手順があります。
+
+ユーザのEメールの設定
+---------------------
+
+ユーザIDは各コミットに保存されます。これは正確だったり一意だったりする必要はありませんが、\
+ログメッセージや注釈で使用されるため、何かしら実在する値を設定しておいた方がよいでしょう。
+
+::
+
+ % bzr whoami "John Doe <jdoe@organization.com>"
+
+
+ローカルリポジトリのセットアップ
+--------------------------------
+
+Bazaar_ のブランチは、通常は履歴のコピーを持っています。そのおかげで分散型での作業ができるわけです。
+最適化の方法の一つとして、関連するブランチ同士の情報を統合して、\
+新しいブランチを作るたびに履歴情報を丸ごとコピーしなくてもいいようにすることができます。
+
+そのための一番いい方法は、 `共用リポジトリ`_ を作成することです。
+一般に、 `共用リポジトリ`_ のサブディレクトリ内に複数のブランチがある場合、お互いの記憶領域を共有します。
+ですので、ホームディレクトリに `共用リポジトリ`_ を作成するようにしましょう。
+そうすれば、その下に作成したすべてのブランチは、履歴情報の領域を共有することになります。
+
+::
+
+ % bzr init-repo --trees ~
+
+
+リモートリポジトリのセットアップ
+---------------------------------
+
+作業用の領域とは別に、データを蓄積しておく領域が欲しいというのはよくあることです。
+集中型のシステム(CVS/SVN)では、このようなワークフローが必要になります。
+たいていは、これらは別々のマシーンに分けて配置されます。(そうでないこともあります。)
+実際のところ、これは、特に職場ではとてもよい設定です。
+蓄積されたデータはバックアップを確実にとることができ、開発者のマシーンに何かトラブルが起こっても\
+コミットされたデータはけっして無くなりません。
+
+それでは、プロジェクト内で共有する ``centralhost`` というマシーンを用意しましょう。
+先ほども言いましたが、ディスクの使用量を節約するために、 `共用リポジトリ`_ を使用します。
+
+::
+
+ % bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/
+
+この手順は、新しくcvsrootやSubversionのリポジトリを作るのと同じようなものだと考えることができます。
+``--no-tree`` オプションの指定によって、ワーキングツリーを作らないようになります。
+中央リポジトリ内のブランチを直接変更することは無いので、このオプションを指定しておくとよいでしょう。
+
+ここで、 ``bzr+ssh`` というURLを使っていますが、これは、 SSH セキュアシェ
+ル上の
+Bazaar 独自プロトコルを意味しています。 bzr+ssh サーバーのセットアップに関
+する
+情報に着いては、管理者向けガイドを参照してください。
+
+
+
+既存のプロジェクトからの移行
+=============================
+
+リポジトリができましたので、プロジェクトの作成にかかりましょう。
+たいていの場合、 Bazaar_ でバージョン管理したい作業中のコードがすでにあるはずです。
+もし、そのコードがもともとソース管理されていたのであれば、履歴の情報を保ったまま Bazaar_ に\
+変換する方法がたくさんあります。
+しかしながら、それについてはここでは説明しません。詳しくは、 `Tracking Upstream`_ の\
+"Converting and keeping history"セクションを見てください。
+
+.. _Tracking Upstream: http://wiki.bazaar.canonical.com/TrackingUpstream
+
+..
+ XXX: プロジェクトの変換について話をするための別の文書が必要なのですが、\
+ 今ある中ではTrackingUpstreamが一番よい文書です。
+
+
+Developer 1: 最初のリビジョンを作成する
+-----------------------------------------
+
+まず最初に、プロジェクトをホストするリモートリポジトリに、ブランチを作成したいと思います。
+仮に、"sigil"というプロジェクトをバージョン管理しようとしているとしましょう。
+
+::
+
+ % bzr init bzr+ssh://centralhost/srv/bzr/sigil
+
+これは、CVSで言うところの"HEAD"ブランチ、Subversionなら"trunk"にあたるものだと考えてかまいません。
+これを ``dev`` ブランチと呼ぶことにしましょう。
+
+他のファイルとの競合を避けるために、ホームディレクトリのサブディレクトリ内で作業するのが私の好みです。
+同じように、最終的にでき上がるすべてのブランチを格納できるプロジェクトディレクトリも欲しいですね。
+::
+
+ % cd ~
+ % mkdir work
+ % cd work
+ % mkdir sigil
+ % cd sigil
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
+ % cd dev
+ % cp -ar ~/sigil/* .
+ % bzr add
+ % bzr commit -m "Initial import of Sigil"
+
+前のセクションでは、空のブランチ(``sigil`` ブランチ)を ``centralhost`` に作成して、\
+それをクライアント端末にチェックアウトしたあと、元々あったプロジェクトのファイルを追加しています。
+作業ディレクトリをセットアップするための方法はたくさんありますが、この方法を使うと機能追加用/バグフィックス用\
+のブランチを使った作業が簡単にできます。
+そして、複数のブランチをとてもうまく扱えるというのが、 Bazaar_ の長所の一つなのです。
+
+この場合、リモートブランチのチェックアウトを持っているので、 ``~/work/sigil/dev/`` に対してコミットした内容が、\
+ローカルと ``centralhost`` の両方に自動的に保存される訳です。
+
+
+Developer N: プロジェクトの作業コピーを取得する
+--------------------------------------------------
+
+プロジェクトの作成に関するすべての作業は1人目の開発者がしてしまっているので、\
+他のみんなは単にそのブランチをチェックアウトするだけです。
+**ただし、** `ユーザのEメールの設定`_ **と** `ローカルリポジトリのセットアップ`_ **は見ておいてください。**
+
+現在開発中のツリーのコピーを取得するためには::
+
+ % cd ~/work/sigil
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
+
+今、二人の人が ``bzr+ssh://centralhost/srv/bzr/sigil`` のチェックアウトを持っている状態なので、\
+片方のチェックアウトが最新のものより古くなってしまうタイミングが出てきます。
+コミットの時に、チェックアウトが古いければ Bazaar_ がエラーを返して、コミットは失敗します。
+チェックアウトを最新にするには、よそで変更されたツリーに対して ``bzr update`` を使用します。
+この時、もし同じファイルが変更されていれば、競合の解決が必要になるかもしれません。
+
+
+別ブランチでの開発
+====================
+
+ここまでは、全員が同じブランチで作業して、変更をコミットしていました。
+これはつまり、全員が適正かつ定期的にアップデートを行い、他の人の変更を取り扱う必要があると\
+いうことです。
+また、誰か一人が何かコードを壊すような変更をコミットして、それが同期されれば、\
+全員が問題を抱えることになります。
+
+たいていの場合、別のブランチ上で開発を行い、コードが安定してからメインのブランチに統合する\
+というやり方の方が優れています。これが、CVSやSVNとの一番大きな違いです。
+CVSやSVNも別ブランチでの開発はできますが、マージのアルゴリズムがかなり貧弱なので、\
+ブランチ間できちんと同期がとれた状態に保つのは難しいことです。
+Bazaar_ は、何がマージ済みかを記憶し、たとえファイルが変名されてる場合でもちゃんと変更を\
+適用することができます。
+
+
+新しいブランチを作成してそこで作業する
+---------------------------------------
+まだ変更が完了していない場合でも、他の人がその変更内容にアクセスできるようにしておきたいですよね。
+そこで、 ``centralhost`` 上に新しい公開ブランチを作成して、それを手元に持ってくることにしましょう。
+
+::
+
+ % cd ~/work/sigil
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
+ bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
+ % cd doodle-fixes
+
+これで、 ``doodle`` に必要な修正を当てるための場所ができました。
+また、他の部分の修正をする人に邪魔されることもありません。
+チェックアウトを持っているため、 ``~/work/sigil/doodle-fixes/`` に対してコミットした内容は\
+``centralhost`` 上にも現れます。
+[#nestedbranches]_ ``dev`` ブランチと同じように、このようなブランチ上で二人の開発者が共同で\
+作業することもできます。
+[#cbranch]_
+
+.. [#nestedbranches] あるブランチのサブディレクトリに別のブランチがあるというのはおかしなこと\
+ に見えるかもしれませんが、これは何もおかしくありません。入れ子になったブランチは外側のブランチ\
+ から派生しているという点で、名前空間の階層と同じようなものだと考えることができます。
+
+.. [#cbranch] たくさんの独立したブランチを使っている場合、毎回フルURLを入力するのは大変です。
+ このURLの入力を簡単にするために、ブランチエイリアスなどたくさんの方法を検討しています。
+ 今のところ、 bzrtools_ プラグインが ``bzr cbranch`` コマンドを提供しています。
+ これは、ベースとなるブランチを指定して、新しく公開ブランチを作成し、そのチェックアウトを作成する\
+ ことを少ない入力でできるように設計されています。
+ ``cbranch`` の使い方についてはこの文書の範囲外ですが、最後のコマンドについてはこんな感じです。:
+
+::
+
+ % bzr cbranch dev my-feature-branch
+
+.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
+
+
+変更内容をマージする
+----------------------
+
+``doodle-fixes`` での変更内容をメインのブランチにマージすることになったら、単にこうするだけです。::
+
+ % cd ~/work/sigil/dev
+ % bzr merge ../doodle-fixes
+
+これで、変更内容は ``dev`` ブランチ上でもアクセスできるようになりますが、まだコミットはされていません。
+最終的な変更内容をレビューして、コードがちゃんとコンパイルでき、テストをパスすることを確認したいならこの時です。
+``bzr status`` コマンドと ``bzr diff`` コマンドがここで役立ちます。
+また、競合を解決するのもこの時です。Bazaar_ では、競合を解決するまではコミットできないようになっています。
+そのため、間違って競合マーカーをコミットしてしまうことはありません。
+``bzr status`` コマンドを使えば、他の変更内容と一緒に競合の情報も表示されます。
+``bzr conflicts`` なら、競合の情報だけが表示されます。
+競合を解決し終わったら、``bzr resolve file/name`` か ``bzr resolve --all`` を実行してください。
+[#resolve]_ もし、解決が特に難しい競合がある場合は、 ``bzr remerge`` コマンドを使いたいと思うかもしれません。
+このコマンドで、別のマージアルゴリズムを試してみることができ、さらに元のソース行を表示する\
+こともできます。(``--show-base``)
+
+.. [#resolve] マージ実行中に競合の解決をさせるシステムもあります。
+ 私たちは、ファイルごとに競合を解決するよりも、ツリー全体を見ながら競合を解決する方がたいていは簡単である\
+ ことに気づきました。
+ そうすれば、よりたくさんの情報を得られますし、問題を解決したときにテストを実行することもできます。
+
+
+推奨のブランチ構成
+---------------------
+
+とても一般的なブランチ構成として、開発者ごとにひとつずつ専用のブランチを割り当て、中央サーバにも開発者ごとの\
+作業領域を用意するという方法があります。これは以下のコマンドでできます。::
+
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
+ bzr+ssh://centralhost/srv/bzr/sigil/user-a
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
+ bzr+ssh://centralhost/srv/bzr/sigil/user-b
+
+これで、開発者ごとに専用の作業用ブランチを割り当てています。
+さらに、開発者自身で [#cbranch]_ を使用して新しく新機能開発用ブランチを作成することも簡単にできます。
+::
+
+ % bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
+ bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
+ % cd ~/work/sigil
+ % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature
+
+
+用語解説
+=========
+
+共用リポジトリ
+--------------
+
+Bazaar_ には、”共用リポジトリ”という概念があります。これは、CVSやSubversionのようなの他のRCSが持つ\
+旧来の概念に似ています。
+たとえば、Subversionでは、サーバ上のリポジトリにすべての履歴情報が保存されていて、手元には履歴情報は\
+全くなく、作業ツリーのファイルのチェックアウトがあるだけです。
+ここで言う”共用”というのは、ブランチ同士の間で共用するという意味であることに注意してください。
+開発者間でも共用される *かも知れません* が、開発者間での共用はスタンドアロンブランチでも可能です。
+
+Bazaar_ の用語では、"共用リポジトリ"とは複数のブランチが履歴情報を **共有** できる場所のことです。
+分散型のワークフローに対応するためには、それぞれのブランチが履歴情報を持っている必要があります。
+しかし、しばしばこれは非効率です。関連するブランチ同士は履歴を共有しており、ディスクも共有した方が\
+いいためです。
+
+
+..
+ vim: tw=74 ft=rst
diff --git a/doc/ja/tutorials/index.txt b/doc/ja/tutorials/index.txt
new file mode 100644
index 0000000..05adeff
--- /dev/null
+++ b/doc/ja/tutorials/index.txt
@@ -0,0 +1,11 @@
+チュートリアル
+==============
+
+.. toctree::
+ :maxdepth: 1
+
+ ../mini-tutorial/index
+ tutorial
+ using_bazaar_with_launchpad
+ centralized_workflow
+ licence
diff --git a/doc/ja/tutorials/licence.txt b/doc/ja/tutorials/licence.txt
new file mode 100644
index 0000000..e15e4e8
--- /dev/null
+++ b/doc/ja/tutorials/licence.txt
@@ -0,0 +1,14 @@
+Licence
+===============
+
+Copyright 2005-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
+
+日本語訳
+==========
+日本語への翻訳は、
+Bazaar-ja <https://groups.google.com/group/bazaar-ja>
+が行っています。質問や間違いの指摘等はこちらへお願いします。
+
diff --git a/doc/ja/tutorials/tutorial.txt b/doc/ja/tutorials/tutorial.txt
new file mode 100644
index 0000000..bc94201
--- /dev/null
+++ b/doc/ja/tutorials/tutorial.txt
@@ -0,0 +1,902 @@
+.. This file is in Python ReStructuredText format - it can be formatted
+.. into HTML or text. In the future we plan to extract the example commands
+.. and automatically test them.
+
+.. This text was previously on the wiki at
+.. http://bazaar.canonical.com/IntroductionToBzr
+.. but has been moved into the source tree so it can be kept in sync with
+.. the source and possibly automatically checked.
+
+======================
+Bazaar チュートリアル
+======================
+
+
+.. Introduction
+
+はじめに
+============
+
+もし、もう分散型バージョン管理に慣れ親しんでいるなら、
+"Bazaarに自己紹介する" の節までとばしてください。
+もし、分散型でないバージョン管理に慣れ親しんでいるけれど分散型バージョン管理は\
+よくわからないのであれば、"分散バージョン管理と分散でないバージョン管理の違い"まで\
+とばしてください。
+それ以外の場合、コーヒーか紅茶(訳注:日本茶でもいいですよ)を用意して、\
+リラックスして読み始めてください。
+
+.. purpose-of-version-control
+
+バージョン管理の目的
+====================
+
+なにかのテキストデータ(プログラムのソースコード、Webサイト、Unixシステムでの\
+設定ファイルなど)を扱う作業をしているとしましょう。
+なにかミスをして、重大なデグレードを引き起こしてしまうかもしれません。
+例えばメールサーバーの設定ファイルを消してしまったり、だいじなプロジェクトの\
+ソースコードを壊してしまったりすることがあります。
+だいじな情報を失って、何が何でも取り戻したいと思った経験があるのであれば、\
+きっとあなたはBazaarを使う準備ができています。
+
+Bazaarをはじめとするバージョン管理システムは、ディレクトリに起こった変更を\
+**ブランチ (branch)** というディレクトリよりも複雑なものの中に入れて\
+管理します。
+ブランチは今ディレクトリの中に何が入っているかだけでなく、過去のいろいろな\
+時点でのディレクトリの中身を格納しています。
+なので、望まぬ変更をしてしまったときには過去の時点の状態に戻すことができます。
+
+バージョン管理システムは、ユーザーが "**リビジョン (revision)** をコミット"
+することで変更をブランチに保存します。
+このときに生成されるリビジョンとは、本質的にいって、前回保存したときからの\
+変更点になります。
+
+リビジョンはそれ以外のものも持っています(原文:These revisions have other
+uses as well.)
+たとえば、オプションのログメッセージをつけることで、変更が何を意味して\
+いるのかというコメントを残すことができます。
+実際に利用されるログメッセージは、 "Webテンプレートをテーブルを閉じるように\
+修正" とか "SFTPに対応した。 #595 を修正。" といったものです。
+
+こういったログが保存されているおかげで、たとえば後になって SFTP に問題が発生\
+したときに、問題が発生するようになったのがどの時点なのか目星をつけることが\
+できます。
+
+
+分散バージョン管理と分散でないバージョン管理の違い
+===================================================
+
+多くのバージョン管理システムはサーバーに配置されています。
+バージョン管理されているコードに対して作業をしたい場合、サーバーに接続して\
+コードを "チェックアウト (checkout)" する必要があります。
+そうすると、変更やコミットができるディレクトリができます。
+バージョン管理システムのクライアントは、バージョン管理システムのサーバーに\
+コミットされた変更を保存します。この方式は集中型として知られています。
+
+集中型にはいくつかの欠点があります。
+集中型バージョン管理システムは、動作するためにサーバーとの接続を要求します。
+このことは、サーバーがどこかインターネット上にあって、あなたのマシンが\
+インターネットに接続できないときに問題になります。
+もしくは、あなたのマシンがインターネットに接続できてもサーバーが落ちている\
+ときにもやはり問題になります。
+
+分散バージョン管理システムは、ブランチをクライアントと同じマシンに置くことで\
+この問題を解決しています。
+Bazaarの場合、ブランチはバージョン管理されているコードと同じディレクトリに\
+保存されます。
+これにより、ユーザーは(たとえオフラインであったとしても)好きなときに変更を保存\
+(**コミット (commit)**)することができます。
+インターネット接続が必要になるのは、どこか別の場所にあるブランチの変更にアクセス\
+するときだけです。
+
+.. TODO:
+.. Performing this tracking by hand is a awkward process that over time
+.. becomes unwieldy. の部分の訳が判らない。
+
+多くの人が必要としていることは、ディレクトリ内でおこったファイルやサブディレクトリ\
+の変更を追跡することです。
+この追跡を手でおこなうのは面倒で不恰好な作業です。
+これは、Bazaarのようなバージョン管理システムの目的のひとつです。
+バージョン管理システムはユーザーが指示したときにディレクトリツリーの
+**リビジョン (revision)** を作ることでこの作業を自動化します。
+
+バージョン管理システムは単に保存したりundoしたりするだけではありません。
+たとえばBazaarでは、ソフトウェアのあるブランチから変更を取り出して、\
+関連する別のブランチに適用することができます。このとき、変更を取り出す\
+ブランチは別の人のものであってもかまいません。これにより、開発者のグループは\
+お互いに書き込み権を与えることなく共同作業することができます。
+
+.. Bazaar remembers the ''ancestry'' of a revision: the previous revisions
+.. that it is based upon. A single revision may have more than one direct
+.. descendant, each with different changes, representing a divergence in the
+.. evolution of the tree. By branching, Bazaar allows multiple people to
+.. cooperate on the evolution of a project, without all needing to work in
+.. strict lock-step. Branching can be useful even for a single developer.
+
+Bazaarではリビジョンの ''親 (ancestry)'' 、つまりそのリビジョンの元になった\
+リビジョンを記録しています。
+ひとつのリビジョンは複数の、それぞれ別の変更を含む子供リビジョンを持つことが\
+あり、それはツリーの進化が分岐していることを意味しています。
+Bazaarではブランチを作ることによって、複数の人が厳しい lock-step をとらなくても\
+協力することができます。
+ブランチを作ることは個人での開発でも便利です。
+
+.. Introducing yourself to Bazaar
+
+Bazaarに自己紹介する
+=====================
+
+.. Bazaar installs a single new command, **bzr**. Everything else is a
+ subcommand of this. You can get some help with ``bzr help``. Some arguments
+ are grouped in topics: ``bzr help topics`` to see which topics are available.
+
+Bazaarは **bzr** という新しいコマンドをひとつインストールします。
+他の全ては bzr のサブコマンドになります。
+``bzr help`` コマンドでいくつかのヘルプを見られます。
+幾つかの話題は topic にまとめられていて、 ``bzr help topics`` で\
+利用可能なトピックの一覧を見られます。
+
+バージョン管理システムの一つの機能は、誰が何を変更したのかを追跡することです。
+分散型バージョン管理システムでは、各開発者がグローバルユニークなIDを持つ\
+必要があります。
+ほとんどの人はこのIDとして利用できる eメールアドレス を持っています。
+Bazaarはコンピュータのユーザー名とホスト名から自動でメールアドレスを\
+生成します。Bazaarが自動で作成したメールアドレス以外のものを使いたい\
+場合、3つの選択肢があります。
+
+1. ``bzr whoami`` を使ってメールアドレスを設定します。これはグローバルなIDを設定\
+ する最も簡単な方法です。グローバルなIDを設定するには::
+
+ % bzr whoami "Your Name <email@example.com>"
+
+ 特定のブランチでべつのアドレスを使いたい場合、そのブランチのディレクトリの\
+ なかで次のコマンドを実行します::
+
+ % bzr whoami --branch "Your Name <email@example.com>"
+
+#. ``?/.bazaar/bazaar.conf`` [1]_ の中のメールアドレスを、以下のようにして\
+ 設定します。 ``[DEFAULT]`` の部分が大文字と小文字を区別するので注意して\
+ ください::
+
+ [DEFAULT]
+ email=Your Name <email@isp.com>
+
+ 特定のブランチにおける設定は、 ``?/.bazaar/locations.conf``
+ にブランチのセクションを作成して次のように書くことができます。 ::
+
+ [/the/path/to/the/branch]
+ email=Your Name <email@isp.com>
+
+
+#. 環境変数 ``$BZR_EMAIL`` もしくは ``$EMAIL`` (``$BZR_EMAIL`` の方が優先\
+ されます)にメールアドレスを設定することで、上の二つの方法で設定された\
+ オプションを上書きすることができます。
+
+.. [1] Windowsではユーザー設定ファイルはアプリケーションデータディレクトリに\
+ おかれます。なので、設定ファイルの場所は ``?/.bazaar/branch.conf`` ではなく\
+ ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``
+ になります。
+ 同じことが ``locations.conf``, ``ignore``, ``plugins`` ディレクトリも\
+ 同じです。
+
+ブランチを作る
+==============
+
+履歴はデフォルトではブランチの .bzr ディレクトリの中に保存されます。
+
+.. これは現行のバージョンでできるのでは?: In a
+ future version of Bazaar, there will be a facility to store it in a
+ separate repository, which may be remote.
+
+既存のディレクトリの中で ``bzr init`` をすると新しいブランチを作成できます::
+
+ % mkdir tutorial
+ % cd tutorial
+ % ls -a
+ ./ ../
+ % pwd
+ /home/mbp/work/bzr.test/tutorial
+ %
+ % bzr init
+ % ls -aF
+ ./ ../ .bzr/
+ %
+
+ファイルには3つのクラス、 unknown, ignored, versioned があります。
+**add** コマンドはファイルを versioned にし、そのファイルへの変更の記録を\
+開始します::
+
+ % echo 'hello world' > hello.txt
+ % bzr status
+ unknown:
+ hello.txt
+ % bzr add hello.txt
+ added hello.txt
+ % bzr status
+ added:
+ hello.txt
+
+もし間違えたファイルを add してしまった場合、そのファイルを unversioned
+状態に戻すために ``bzr remove`` してください。
+この場合の ``bzr remove`` は、ほかの場合 [2]_ とちがってファイルを削除\
+しません。
+
+.. [2] ``bzr remove`` はファイルがバージョン管理されていて何も変更されて\
+ いない場合に、そのファイルを削除します。 ``--keep`` オプションで常に\
+ ファイルを残すことができます。 ``--force`` オプションで常にファイルを\
+ 削除することもできます。
+
+.. Branch locations
+
+ブランチの場所
+===============
+
+すべての履歴はブランチに格納されます。ブランチとは、管理用のファイルを\
+含んだただのディレクトリです。デフォルトでは、svnやsvkのような、分離した\
+リポジトリやデータベースはありません。分離したリポジトリを作成することも\
+できます(``bzr init-repo`` コマンドを参照してください)。大規模なブランチを\
+利用する場合や、中規模のブランチをたくさん利用する場合にはリポジトリを\
+分離するといいでしょう。
+
+自分のコンピュータのファイルシステム上にあるブランチを参照するときは\
+ブランチを格納しているディレクトリ名で指定できます。 bzr は SSH, HTTP
+SFTP などを経由してブランチにアクセスすることもできます。例::
+
+ % bzr log bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+ % bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+ % bzr log sftp://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+
+プラグインをインストールすれば、 rsync プロトコルを使ってブランチにアクセス\
+することもできます。
+
+ブランチを指定した場所に置く方法については、 `ブランチを公開する`_ 節を\
+ご覧ください。
+
+.. Reviewing changes
+
+変更をレビューする
+===================
+
+一仕事終えたら、それを履歴に **コミット (commit)** しましょう。
+新しい機能を追加したり、バグを直したり、コードやドキュメントを更新したら\
+いつでもコミットするのは良いことです。
+すべてのリビジョンが良い状態であるようにするために、コミットする前にコードを\
+コンパイルしたりテストスイートを実行するのも良い習慣です。
+コミットする前にコミットしようとしているものを確認するためにレビューすることが\
+できます。
+
+この目的で便利な二つのコマンドがあります。 **status** と **diff** です。
+
+bzr status
+----------
+
+**status** コマンドは、今の作業ツリーが最後のリビジョンからどのように\
+変更されたのかを教えてくれます::
+
+ % bzr status
+ modified:
+ foo
+
+``bzr status`` は変更が無かったり無視されているファイルを隠します。
+status コマンドはオプションとして、確認対象となる複数のファイル名やディレクトリ名を\
+渡すことができます。
+
+bzr diff
+--------
+
+**diff** コマンドは通常の unified diff フォーマットですべてのファイルの\
+テキストの変更を表示します。
+このコマンドの出力を pipe 経由で、''patch'', ''diffstat'', ''fileterdiff'',
+''colordiff'' といったコマンドに渡すことができます。 ::
+
+ % bzr diff
+ === added file 'hello.txt'
+ --- hello.txt 1970-01-01 00:00:00 +0000
+ +++ hello.txt 2005-10-18 14:23:29 +0000
+ @@ -0,0 +1,1 @@
+ +hello world
+
+
+``-r`` オプションをつけると、作業ツリーを古いリビジョンと比較したり、\
+二つのリビジョン間の差分を見ることができます。 ::
+
+ % bzr diff -r 1000.. # everything since r1000
+ % bzr diff -r 1000..1100 # changes from 1000 to 1100
+
+``--diff-options`` オプションをつけると、 bzr は外部の diff プログラムに\
+オプションをつけて起動します。 例::
+
+ % bzr diff --diff-options --side-by-side foo
+
+プロジェクトによっては二つのファイルに接頭辞がついた patch が好まれます。
+``--prefix`` オプションでそのような接頭辞をつけることができます。
+ショートカットとして、 ``bzr diff -p1`` は ``patch -p1`` コマンドが受け付ける\
+形で差分を出力します。
+
+
+.. Committing changes
+
+変更をコミットする
+==================
+
+作業ツリーの状態に満足したら、ブランチに **コミット (commit)** しましょう。
+コミットとは作業ツリーの状態のスナップショットを保持するリビジョンを新しく作ることです。
+
+bzr commit
+----------
+
+.. The **commit** command takes a message describing the changes in the
+.. revision. It also records your userid, the current time and timezone, and
+.. the inventory and contents of the tree. The commit message is specified
+.. by the ``-m`` or ``--message`` option. You can enter a multi-line commit
+.. message; in most shells you can enter this just by leaving the quotes open
+.. at the end of the line.
+
+**commit** コマンドはそのリビジョンの変更を説明するメッセージを受け取ります。
+また、あなたのユーザーID、今の時間とタイムゾーン、ツリーの内容をあわせて記録します。
+コミットメッセージは ``-m`` もしくは ``--message`` オプションで指定できます。
+複数行のコメントも利用できます。多くのシェルはクォートを開いたままで改行する\
+ことで複数行の入力が可能です。
+
+::
+
+ % bzr commit -m "added my first file"
+
+.. You can also use the ``-F`` option to take the message from a file. Some
+.. people like to make notes for a commit message while they work, then
+.. review the diff to make sure they did what they said they did. (This file
+.. can also be useful when you pick up your work after a break.)
+
+メッセージをファイルで渡すには ``-F`` オプションを使います。
+コミットメッセージを先に作成し、それとdiffを合わせてレビューすることで、
+コミットメッセージとコミット内容が一致していることを確認する人もいます。
+(このファイルは休憩から戻ってきて作業を思い出すときにも役に立つでしょう)
+
+.. Message from an editor
+
+エディタからメッセージを入力する
+----------------------------------
+
+.. If you use neither the ``-m`` nor the ``-F`` option then bzr will open an
+.. editor for you to enter a message. The editor to run is controlled by
+.. your ``$VISUAL`` or ``$EDITOR`` environment variable, which can be overridden
+.. by the ``editor`` setting in ``?/.bazaar/bazaar.conf``; ``$BZR_EDITOR`` will
+.. override either of the above mentioned editor options. If you quit the
+.. editor without making any changes, the commit will be cancelled.
+
+``-m`` オプションも ``-F`` オプションも指定しなかった場合、 bzr はメッセージを\
+入力するためにエディタを立ち上げます。
+このエディタは ``$VISUAL`` か ``$EDITOR`` 環境変数で制御することができます。
+この環境変数を `` /.bazaar/bazaar.conf`` 内の ``editor`` を設定して上書き\
+することができ、さらに ``$BZR_EDITOR`` 環境変数がそれらすべてを上書きします。
+もし何も変更せずにエディタを閉じたなら、コミットはキャンセルされます。
+
+.. The file that is opened in the editor contains a horizontal line. The part
+.. of the file below this line is included for information only, and will not
+.. form part of the commit message. Below the separator is shown the list of
+.. files that are changed in the commit. You should write your message above
+.. the line, and then save the file and exit.
+
+エディタで開かれるファイルには水平線が含まれています。この線より下の部分は\
+参考用であり、コミットメッセージには含まれません。
+水平線の下にはコミットで変更されるファイルのリストが表示されます。
+メッセージは水平線の上に書く必要があります。そうしたら、ファイルを保存して\
+エディタを終了してください。
+
+.. If you would like to see the diff that will be committed as you edit the
+.. message you can use the ``--show-diff`` option to ``commit``. This will include
+.. the diff in the editor when it is opened, below the separator and the
+.. information about the files that will be committed. This means that you can
+.. read it as you write the message, but the diff itself wont be seen in the
+.. commit message when you have finished. If you would like parts to be
+.. included in the message you can copy and paste them above the separator.
+
+``commit`` コマンドに ``--show-diff`` オプションをつけると、コミットされる\
+変更の diff を見ることができます。この diff はエディタが開いたときに水平線\
+やコミットされるファイルの情報よりも下に含まれます。
+なので、コミットメッセージを書くときに diff を見ることができますが、\
+コミットメッセージ自体には diff が含まれません。
+コミットメッセージに diff を含めたい場合は、水平線より上にコピーペースト\
+してください。
+
+
+.. Marking bugs as fixed
+
+解決したバグの記録をつける
+----------------------------
+
+プロジェクトにおいて多くの変更はバグの修正のために行われます。
+Bazaar は、コミットするときに解決したバグについてメタデータに記録することが
+できます。
+これを行うには、 ``--fixes`` オプションを使います。
+このオプションは次のような形の引数を取ります。
+
+ % bzr commit --fixes <tracker>:<id>
+
+``<tracker>`` の部分にはバグ管理システムを指定するIDを書き、
+``<id>`` の部分にはそのバグ管理システム上で管理されているバグの
+IDを書きます。 ``<id>`` はたいてい数値になるでしょう。
+Bazaar は最初からいくつかの有名なバグ管理システムを知っています。
+bugs.launchpad.net, bugs.debian.org bugzilla.gnome.org です。
+これらは、それぞれ独自のIDとして lp, deb, gnome を持っています。
+例えば、 bugs.launchpad.net 上のバグ #1234 を解決する場合は、
+その解決をコミットするときに次のようなコマンドを利用できます。 ::
+
+ % bzr commit -m "fixed my first bug" --fixes lp:1234
+
+For more information on this topic or for information on how to configure
+other bug trackers please read `Bug Tracker Settings`_.
+
+このトピックに着いてのさらなる情報や、他のバグ管理システムを設定する方法
+については、 `Bug Tracker Settings`_ を参照してください。
+
+.. _Bug Tracker Settings: ../user-reference/index.html#bug-tracker-settings
+
+.. Selective commit
+
+選択コミット
+----------------
+
+.. If you give file or directory names on the commit command line then only
+.. the changes to those files will be committed. For example::
+
+commit コマンドにファイル名やディレクトリ名を渡したとき、それらのファイルの\
+変更だけがコミットされます。 例 ::
+
+ % bzr commit -m "documentation fix" commit.py
+
+.. By default bzr always commits all changes to the tree, even if run from a
+.. subdirectory. To commit from only the current directory down, use::
+
+デフォルトでは bzr は、サブディレクトリから実行される場合でもすべての変更を\
+コミットします。
+カレントディレクトリ以下だけをコミットする場合は、次のようにします ::
+
+ % bzr commit .
+
+
+.. Removing uncommitted changes
+
+コミットされていない変更を削除する
+===================================
+
+.. If you've made some changes and don't want to keep them, use the
+.. **revert** command to go back to the previous head version. It's a good
+.. idea to use ``bzr diff`` first to see what will be removed. By default the
+.. revert command reverts the whole tree; if file or directory names are
+.. given then only those ones will be affected. ``bzr revert`` also clears the
+.. list of pending merges revisions.
+
+不要な変更がある場合、 **revert** コマンドで最後のリビジョンの状態に戻る\
+ことができます。
+revert するまえに ``bzr diff`` で何が削除されるのかを確認しておくと良いでしょう。
+デフォルトでは revert コマンドはツリー全体を revert します。ファイル名や\
+ディレクトリ名が指定されている場合は、そのファイルだけが revert されます。
+``bzr revert`` はマージ待ちリビジョンのリストも削除します。
+
+
+.. Ignoring files
+
+ファイルを無視する
+===================
+
+.. The .bzrignore file
+
+.bzrignore ファイル
+-------------------
+
+.. Many source trees contain some files that do not need to be versioned,
+.. such as editor backups, object or bytecode files, and built programs. You
+.. can simply not add them, but then they'll always crop up as unknown files.
+.. You can also tell bzr to ignore these files by adding them to a file
+.. called ``.bzrignore`` at the top of the tree.
+
+多くのソースツリーはバージョン管理する必要のないファイルをたくさん含んでいます。
+たとえば、エディタのバックアップファイルや、オブジェクトファイル、バイトコード、
+ビルドされたプログラムなどです。
+こういったファイルを単に add しないこともできますが、そうすると毎回 unknown file
+としてたびたび出現することになります。
+ツリートップにある ``.bzrignore`` とよばれるファイルにそれらのファイルを追加する\
+ことで、bzrにそれらのファイルを無視させることができます。
+
+.. This file contains a list of file wildcards (or "globs"), one per line.
+.. Typical contents are like this::
+
+このファイルは行ごとにワイルドカード (もしくは"glob") のリストを含みます。
+典型的な内容の例です::
+
+ *.o
+ *?
+ *.tmp
+ *.py[co]
+
+.. If a glob contains a slash, it is matched against the whole path from the
+.. top of the tree; otherwise it is matched against only the filename. So
+.. the previous example ignores files with extension ``.o`` in all
+.. subdirectories, but this example ignores only ``config.h`` at the top level
+.. and HTML files in ``doc/``::
+
+glob がスラッシュを含む場合、ツリーのトップからのパス全体にマッチします。
+そうでない場合は、単にファイル名にマッチします。
+なので、上の例はすべてのサブディレクトリの ``.o`` 拡張子を持つファイルを無視\
+しますが、次の例ではツリーのトップにある ``config.h`` ファイルと、 ``doc/``
+ディレクトリ以下のHTMLファイルだけを無視します::
+
+ ./config.h
+ doc/*.html
+
+.. To get a list of which files are ignored and what pattern they matched,
+.. use ``bzr ignored``::
+
+どのファイルがどのパターンにマッチして無視されているのかを、 ``bzr ignored``
+コマンドで表示することができます::
+
+ % bzr ignored
+ config.h ./config.h
+ configure.in? *?
+
+.. It is OK to have either an ignore pattern match a versioned file, or to
+.. add an ignored file. Ignore patterns have no effect on versioned files;
+.. they only determine whether unversioned files are reported as unknown or
+.. ignored.
+
+バージョン管理されているファイルが無視パターンにマッチしたり無視リストに\
+入っていても大丈夫です。無視パターンはバージョン管理されたファイルには\
+影響しません。バージョン管理されていないファイルを 'unknown' として扱うか\
+'ignored' として扱うかを決めるためだけに使われます。
+
+
+.. The ``.bzrignore`` file should normally be versioned, so that new copies
+.. of the branch see the same patterns::
+
+``.bzrignore`` ファイルは普通はバージョン管理されます。なのでそのブランチの\
+コピーでも同じパターンが無視されます。 ::
+
+ % bzr add .bzrignore
+ % bzr commit -m "Add ignore patterns"
+
+
+bzr ignore
+----------
+
+``.bzrignore`` ファイルを直接編集する代わりに、 ``bzr ignore`` コマンドを
+利用することができます。 ``bzr ignore`` コマンドはファイル名かパターンを
+引数に受け取って、それを ``.bzrignore`` ファイルに追加します。
+``.bzrignore`` ファイルが存在しない場合、 ``bzr ignore`` コマンドは
+自動的にそのファイルを作成してバージョン管理に追加します。 ::
+
+ % bzr ignore tags
+ % bzr status
+ added:
+ .bzrignore
+
+
+``.bzrignore`` ファイルを自分で修正したときと同じく、コマンドを実行したあとに
+``.bzrignore`` ファイルをコミットしなければなりません。 ::
+
+ % bzr commit -m "Added tags to ignore file"
+
+
+.. Global ignores
+
+グローバルの無視設定
+---------------------
+
+.. There are some ignored files which are not project specific, but more user
+.. specific. Things like editor temporary files, or personal temporary files.
+.. Rather than add these ignores to every project, bzr supports a global
+.. ignore file in ``?/.bazaar/ignore`` [1]_. It has the same syntax as the
+.. per-project ignore file.
+
+エディタの一時ファイルや個人の一時ファイルなど、\
+幾つかの無視ファイルはプロジェクト依存ではなくてユーザー依存です。
+こういったファイルを全プロジェクトで無視設定するかわりに、グローバルの\
+無視設定ファイル ``~/.bazaar/ignore`` を利用できます。
+これはプロジェクトの ignore ファイルと同じ文法で記述します。
+
+
+.. Examining history
+
+履歴を閲覧する
+===============
+
+bzr log
+-------
+
+.. The ``bzr log`` command shows a list of previous revisions. The ``bzr log
+.. --forward`` command does the same in chronological order to get most
+.. recent revisions printed at last.
+
+``bzr log`` コマンドは過去のリビジョンのリストを表示します。
+``bzr log --forward`` コマンドは同じ内容を、時系列順で最新のものが最後に\
+くるように出力します。
+
+.. As with ``bzr diff``, ``bzr log`` supports the ``-r`` argument::
+
+``bzr diff`` と同じように、 ``bzr log`` も ``-r`` 引数をサポートします::
+
+ % bzr log -r 1000.. # リビジョン r1000 とそれ以降すべて
+ % bzr log -r ..1000 # r1000 とそれ以前のすべて
+ % bzr log -r 1000..1100 # r1000 から r1100 まで
+ % bzr log -r 1000 # リビジョン r1000 だけ
+
+.. % bzr log -r 1000.. # Revision 1000 and everything after it
+.. % bzr log -r ..1000 # Everything up to and including r1000
+.. % bzr log -r 1000..1100 # changes from 1000 to 1100
+.. % bzr log -r 1000 # The changes in only revision 1000
+
+
+.. Branch statistics
+
+ブランチの情報
+=================
+
+.. The ``bzr info`` command shows some summary information about the working
+.. tree and the branch history.
+
+``bzr info`` コマンドは作業ツリーとブランチの履歴に関する情報の要約を表示します。
+
+
+.. Versioning directories
+
+ディレクトリをバージョン管理する
+================================
+
+.. bzr versions files and directories in a way that can keep track of renames
+.. and intelligently merge them::
+
+bzr はファイルとディレクトリを、名前の変更を追跡して賢くマージできるように\
+バージョン管理します::
+
+ % mkdir src
+ % echo 'int main() {}' > src/simple.c
+ % bzr add src
+ added src
+ added src/simple.c
+ % bzr status
+ added:
+ src/
+ src/simple.c
+
+
+.. Deleting and removing files
+
+ファイルを削除する
+===================
+
+.. You can delete files or directories by just deleting them from the working
+.. directory. This is a bit different to CVS, which requires that you also
+.. do ``cvs remove``.
+
+ファイルを削除するのは、単純に作業ツリーからファイルを削除するだけでできます。
+これは、 ``cvs remove`` が必要な CVS とは少し異なります。
+
+.. ``bzr remove`` makes the file un-versioned, but may or may not delete the
+.. working copy [2]_. This is useful when you add the wrong file, or decide that
+.. a file should actually not be versioned.
+
+``bzr remove`` はファイルをバージョン管理対象からはずしますが、作業ツリーから\
+削除することも削除しないこともできます。 [2]_
+これは間違ったファイルを追加してしまったり、あるファイルをバージョン管理するのを\
+やめる場合に便利です。
+
+::
+
+ % rm -r src
+ % bzr remove -v hello.txt
+ ? hello.txt
+ % bzr status
+ removed:
+ hello.txt
+ src/
+ src/simple.c
+ unknown:
+ hello.txt
+
+.. If you remove the wrong file by accident, you can use ``bzr revert`` to
+.. restore it.
+
+もし間違ってファイルを削除してしまった場合、 ``bzr revert`` でリストアできます。
+
+
+.. Branching
+
+ブランチを作る
+==============
+
+.. Often rather than starting your own project, you will want to submit a
+.. change to an existing project. To do this, you'll need to get a copy of
+.. the existing branch. Because this new copy is potentially a new branch,
+.. the command is called **branch**::
+
+自分でプロジェクトを始めるのではなく、既存のプロジェクトに変更を加えたい場合があります。
+この場合、既存のブランチのコピーを取得する必要があります。
+このコピーは新しいブランチになるので、このコマンドは **branch** という名前になっています::
+
+ % bzr branch lp:bzr bzr.dev
+ % cd bzr.dev
+
+.. This copies down the complete history of this branch, so we can do all
+.. operations on it locally: log, annotate, making and merging branches.
+.. There will be an option to get only part of the history if you wish.
+
+.. XXX: There will be の訳これでいい?
+
+これでブランチの完全な履歴をコピーできたので、すべての操作 (log, annotate,
+branch の作成とマージなど) をローカルで実行できます。
+履歴の一部だけを取得するオプションも追加される予定です。
+
+.. You can also get a copy of an existing branch by copying its directory,
+.. expanding a tarball, or by a remote copy using something like rsync.
+
+既存のブランチをコピーするには、普通にディレクトリをコピーしたり、tarballを\
+展開したり、リモートから rsync のような方法でコピーすることもできます。
+
+.. Following upstream changes
+
+上流の変更を追いかける
+==========================
+
+.. You can stay up-to-date with the parent branch by "pulling" in their
+ changes::
+
+変更を "pull" することで手元のブランチを上流のブランチに対して最新に保つことが\
+できます。
+
+ % bzr pull
+
+.. After this change, the local directory will be a mirror of the source. This
+.. includes the ''revision-history'' - which is a list of the commits done in
+.. this branch, rather than merged from other branches.
+
+.. XXX This includes~がわからない.
+
+このコマンドを実行した後、ローカルディレクトリはpull元のミラーになります。
+ミラーするものには、 ''revision-history'' を含みます。つまり、別のブランチから\
+マージするのではなくて、このブランチに対してコミットした履歴になります。
+
+.. This command only works if your local (destination) branch is either an
+.. older copy of the parent branch with no new commits of its own, or if the
+.. most recent commit in your local branch has been merged into the parent
+.. branch.
+
+このコマンドはローカルの(pull先)ブランチが親ブランチの古いコピーで独自の\
+あたらしいリビジョンを一切含まないか、ローカルブランチへの最新のコミットが\
+親ブランチにマージされているときにのみ成功します。
+
+.. Merging from related branches
+
+関連ブランチからマージする
+=============================
+
+.. If two branches have diverged (both have unique changes) then ``bzr
+.. merge`` is the appropriate command to use. Merge will automatically
+.. calculate the changes that exist in the branch you're merging from that
+.. are not in your branch and attempt to apply them in your branch.
+
+二つのブランチが分岐している(互いに異なる変更を持っている)とき、
+``bzr merge`` コマンドの出番です。
+merge はマージ元ブランチにあって手元のブランチにない変更を自動で探して、\
+その変更を手元に適用しようと試みます。
+
+::
+
+ % bzr merge URL
+
+
+.. If there is a conflict during a merge, 3 files with the same basename
+.. are created. The filename of the common base is appended with ".BASE",
+.. the filename of the file containing your changes is appended with
+.. ".THIS" and the filename with the changes from the other tree is
+.. appended with ".OTHER". Using a program such as kdiff3, you can now
+.. comfortably merge them into one file. In order to commit you have to
+.. rename the merged file (".THIS") to the original file name. To
+.. complete the conflict resolution you must use the resolve command,
+.. which will remove the ".OTHER" and ".BASE" files. As long as there
+.. exist files with .BASE, .THIS or .OTHER the commit command will
+.. report an error.
+
+マージ中に衝突(conflict)が発生した場合、同じ基本名(basename)をもつ\
+3つのファイルが作成されます。
+共通の祖先になるファイルのファイル名には ".BASE" が、
+手元のブランチの変更を含むファイル名には ".THIS" が、
+マージ元の変更を含むファイル名には ".OTHER" が末尾に追加されます。
+kdiff3 のようなプログラムを利用してこれらのファイルをひとつに\
+マージすることができます。
+コミットするには、マージされた ".THIS" ファイルを元のファイル名に\
+リネームします。
+衝突の解決を完了するには、 resolve コマンドを使います。
+このコマンドは ".OTHER" と ".BASE" ファイルを削除します。
+.BASE, .THIS, .OTHER ファイルが残っている場合、 commit コマンドは\
+エラーを報告します。
+
+::
+
+ % kdiff3 file.BASE file.OTHER file.THIS
+ % mv file.THIS file
+ % bzr resolve file
+
+[**TODO**: explain conflict markers within files]
+
+
+ブランチを公開する
+======================
+
+.. You don't need a special server to publish a bzr branch, just a normal web
+.. server. Just mirror the files to your server, including the .bzr
+.. directory. One can push a branch (or the changes for a branch) by one of
+.. the following three methods:
+
+bzrのブランチを公開するには特別なサーバーは必要ありません、普通のWebサーバーが\
+使えます。
+.bzr ディレクトリを含めてファイルをサーバーにミラーしてください。
+ブランチをpush(やブランチに対する操作)するのに以下の3つの方法があります。
+
+.. * The best method is to use bzr itself to do it.
+
+* 最良の方法は bzr 自体を使うことです。
+
+ ::
+
+ % bzr push bzr+ssh://servername.com/path/to/directory
+
+.. (The destination directory must already exist unless the
+.. ``--create-prefix`` option is used.)
+
+ (push先ディレクトリがすでに存在するか、 ``--create-prefix`` オプションを\
+ 利用する必要があります。)
+
+.. * Another option is the ``rspush`` plugin that comes with BzrTools, which
+.. uses rsync to push the changes to the revision history and the working
+.. tree.
+
+* 別の選択肢は bzrtools に含まれる ``rspush`` プラグインを利用することです。
+ これはリモートの履歴と作業ツリーに変更を push するのに rsync を利用します。
+
+.. * You can also copy the files around manually, by sending a tarball, or using
+.. rsync, or other related file transfer methods. This is usually less safe
+.. than using ``push``, but may be faster or easier in some situations.
+
+* tarball を送ったり rsync を使ったりほかの転送方法を利用して、手動でファイルを\
+ コピーすることもできます。
+ これはたいてい ``push`` ほど安全ではありませんが、場合によって高速だったり、\
+ 簡単だったりするかもしれません。
+
+
+.. Moving changes between trees
+
+変更をツリー間で移動する
+============================
+
+.. It happens to the best of us: sometimes you'll make changes in the wrong
+.. tree. Maybe because you've accidentally started work in the wrong directory,
+.. maybe because as you're working, the change turns out to be bigger than you
+.. expected, so you start a new branch for it.
+
+どんな人にでもありえることですが、適切ではないツリー上で変更してしまうことがあります。
+単純に作業するディレクトリを間違えたり、変更が予想よりも大きくなってしまったりして、
+その変更のために新しいブランチを作りなおすことがあります。
+
+.. To move your changes from one tree to another, use
+
+変更をあるツリーから別のツリーに移動するには
+
+::
+
+ % cd NEWDIR
+ % bzr merge --uncommitted OLDDIR
+
+.. This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
+.. It will not apply committed changes, even if they could be applied to NEWDIR
+.. with a regular merge. The changes will remain in OLDDIR, but you can use ``bzr
+.. revert OLDDIR`` to remove them, once you're satisfied with NEWDIR.
+
+これですべてのコミットされていないOLDDIR上の変更がNEWDIRに適用されます。
+コミットされていない変更は、通常のmergeでNEWDIRに適用することができる場合でも適用されません。
+OLDDIR上の変更はそのまま残りますが、NEWDIRの状態に満足したら ``bzr revert OLDDIR``
+で削除することができます。
+
+.. NEWDIR does not have to be a copy of OLDDIR, but they should be related.
+.. The more different they are, the greater the chance of conflicts.
+
+NEWDIRはOLDDIRのコピーである必要はありませんが、関連しているべきです。
+両者の違いが大きければそれだけ衝突が起こる可能性が大きくなります。
diff --git a/doc/ja/tutorials/using_bazaar_with_launchpad.txt b/doc/ja/tutorials/using_bazaar_with_launchpad.txt
new file mode 100644
index 0000000..6d36204
--- /dev/null
+++ b/doc/ja/tutorials/using_bazaar_with_launchpad.txt
@@ -0,0 +1,459 @@
+===========================
+LaunchpadでBazaarを使う
+===========================
+
+
+動機付け
+==========
+
+コミュニティはチームとは違う
+----------------------------------
+
+ソフトウェアの初回リリースをしなければならない人々のチームというのは、\
+一人から数千人まで、その規模は多岐に渡ります。
+その要求に応じて、技術的な課題、経営上の課題、その両方が非常に大きなもの\
+になる可能性があります。
+Bazaarユーザガイドで説明したように、"ふさわしい"プロセスを選択し、\
+それに見合ったワークフローをサポートするBazaarのようなツールを使うことは、\
+大きな手助けになるでしょう。
+
+しかし、ソフトウェアによる成功のためには、すばらしいチーム以上のものが\
+必要です。 - それは、健全で活発な *コミュニティ* です。
+このグループは、通常はチームよりもはるかに大きく、なぜならそのソフトウェアに\
+関心のあるすべての人 - 開発チーム、ユーザ、トレーニングパートナー、\
+サポートパートナー、サードパーティの開発者など - を含むからです。
+
+すばらしいコミュニティというものはフリー(自由)ソフトウェア
+コミュニティでは良く理解されています。
+しかし、その適用はオープンソースの世界を越えて広がっています。
+もっとも成功している商業ソフトウェアのベンダーは、
+そのフラッグシッププロダクトと共に成長するコミュニティ\
+を作り上げ、運営することがたくみなのです。
+
+すばらしいチームと同じように、すばらしいコミュニティも偶然できるものではありません。
+良いポリシーとガイドラインが、参加者同士の健全なコミュニケーションと正しい振る舞い\
+を育てるために不可欠です。
+この話題についてもっと深く知りたければ、Karl Fogelのすばらしい著書 - \
+`Producing Open Source Software <http://www.producingoss.com/>`_ - を見てください。
+
+
+協調開発に必要なもの
+---------------------------------------------------
+
+コミュニティの情報とワークフローを追跡し、管理するためには、賢いツールセットが重要です。
+そのようなツールを、協調開発環境(Collaborative Development Environments : CDEs)と呼びます。
+一般的には、WEBベースでアナウンスや案件、バグを管理します。
+`Launchpad <https://launchpad.net>`_ 、
+`SourceForge <http://sourceforge.net>`_ 、
+`java.net <http://java.net>`_ 、
+`SAP Community Network <https://www.sdn.sap.com/irj/sdn>`_ などに、CDEsの例があります。
+
+関係するコミュニティとの協調を助ける
+-------------------------------------------------
+
+多くの成功しているプロダクトは、その下流にそれを使うたくさんのプロダクトがあります。
+言いかえると、他のコミュニティとやりとりをして、自分の変更が彼らにどんな影響を与えるかを\
+理解することで、新しい挑戦が成功するのです。
+これは、以下のようなプロダクトでは特に明白です。:
+
+* プログラム言語、たとえばPyhon、PHP、Ruby、Java、Perlなど
+* コンパイラ、たとえばgcc、JDKなど
+* ライブラリ、たとえばzlib、opensslなど
+* フレームワーク、たとえばZope、Ruby on Rails、Springなど
+
+.. XXX downstream dependenciesは、直訳だとわかりづらい気がするのでやや意訳
+ In other wordからの一文の訳がよくわからない
+
+.. Many successful products have a huge number of downstream dependencies.
+ In other words, a new challenge arises with success: dealing with other
+ communities and understanding how your changes will impact them. This is
+ most obvious for projects like:
+
+しかし、アドオン機能を持つメジャーなアプリケーション、たとえばFirefox、Thundervird、\
+OpenOffice.org、Drupal、Wordpress、Joomlaなどにも、このことはあてはまります。
+
+コミュニティの境界をこえて案件や障害修正の追跡と管理をするための作業をサポートして\
+くれるツールが必要です。
+そのようなツールは、両極端にいるどちらのユーザも助けてくれます。:
+
+* 自分のことばで問題を報告することができるユーザ。
+ たとえば、「オペレーションシステムX上のアプリケーションYで、Zタイプのイメージの\
+ レンダリングがおかしい」など
+
+* 変更や障害修正が下流のプロダクトに与える影響をよりよく評価できる開発者。
+ たとえば、「グラフィックライブラリのバグを修正することにより、これらの10個のOS上の\
+ 5つのアプリケーションに恩恵がある」など
+
+その間にいる人々は、 *点線をつなぎ* 、上流と下流との間のコミュニケーションを担うという\
+重要な役割を果たします。
+多くの場合、彼らはエンドユーザのためにバグを修正したり、パッチをリリースしたり、上流の\
+開発チームに修正内容を提示したりします。
+それらすべてを持続可能な方法で常に追跡しつづけることは、簡単なことではありません。
+
+Launchpad: 開発をもっと効果的に、摩擦は少なく
+-------------------------------------------------
+
+Canonical は、 `Ubuntu <http://www.ubuntu.com>`_ や `Bazaar <http://bazaar.canonical.com>`_
+の開発に出資しているのと同じように、
+オープンソースコミュニティ向けの無料のサービスとして
+Launchpad <https:launchpad.net> も提供しています。
+Launchpadは、以下の注目すべき理由から、もっともエキサイティングな
+CDEsのひとつです。
+
+* トラッキング対象のたくさんのもの同士の関係を具体化しています。
+ たとえば、ソースコードのブランチをバグ修正に関連づけることができます。
+
+* これまでの資産を管理するのと同じように、ロードマップ、マイルストーン、ブループリントの\
+ 機能によってこれからの開発の計画や追跡もできます。
+
+* 翻訳ツールやパッケージングサービスを提供することで、翻訳者やテスターがコミュニティに参加し、\
+ 貢献するときの抵抗を少なくしています。
+
+* 違うコミュニティ同士が、関連する案件やロードマップに対してともに作業するための結びつきを\
+ 提供します。
+
+言いかえると、Launchpadは、あなたのコミュニティの成長を助け、 *コミュニティ内* と\
+*コミュニティ間* との両方でワークフローの摩擦を減らすようにデザインされています。
+究極的には、機械的なタスクにつかう時間をなくし、興味ぶかい開発により多くの時間を\
+さけるようにすることを意味しています。
+
+Bazaar: Launchpadのバージョン管理クライアント
+---------------------------------------------
+
+このチュートリアルは、BazaarとLaunchpadがどのようにして一緒に使うことができ、\
+どれだけお互いを引き立てあうのかを考えます。
+以下のことは覚えておいてください。:
+
+1. BazaarはLaunchpadなしで使うこともできます。
+2. LaunchpadはBazaarなしで使うこともできます。
+
+それでも、別々に使うよりも一緒に使った方がより大きな力を発揮するように設計されています。
+
+
+Launchpadでのブランチの検索、閲覧
+===================================
+
+利用できるブランチの検索
+--------------------------
+
+分散型バージョン管理を導入することには多くの利点がありますが、できなくなってしまうこと\
+のひとつとして、利用できるすべてのブランチについて知っている中央サーバがないという点が\
+あります。
+実際、分散環境では、関連するブランチは、インターネット中の文字どおり100もの場所に存在する\
+可能性があります。(もしくは、イントラネットの中でも同様です。)
+
+Launchpadは、ブランチのデータベースを提供することによって、このギャップをなくします。
+
+ブランチの登録
+--------------------
+
+ブランチはLaunchPadにアップロードすることもできますし、別の場所にあるブランチを単に登録する\
+こともできます。
+また、ブランチには *New(新規)* 、 *Development(開発バージョン)* 、 *Mature(安定)* 、 *Abandoned(破棄)*
+というステータスを付加することができます。
+
+Note: 外部のブランチは、CVSやSubversionのような従来のバージョン管理ツールでホストされて\
+いても構いません。
+これらのシステム上のコードは定期的にスキャンされ、Bazaarのブランチに変換されます。
+もちろん、最大限の正確さを求めるのであれば、外部のブランチをBazaarでホストすることが望ましいです。
+
+ブランチの閲覧
+-----------------
+
+ブランチは、名前、登録者、作者、ステータス、世代、最終コミット時刻などの多くの属性によって\
+リストアップやフィルタリング、並べ替えができます。
+また、ブランチを閲覧することによって、以下のようなことが簡単に分かります。:
+
+* ブランチがどこからダウンロードできるか
+* 変更をアップロードする方法
+* それぞれで行った最近のコミットと変更内容
+* 指定したバージョンの個々のファイルのソースコード
+
+
+Launchpad上のコードへのBazaarでのアクセス
+=========================================
+
+プロジェクトのコードの取得
+----------------------------
+
+Launchpad 上には多数のプロジェクトがあり、その最新のコードがBazaarで
+管理されていても、CVSやSubversionで管理されていても、Bazaarを使って
+以下のように簡単にコードを取得することができます。 ::
+
+ bzr branch lp:project-name
+
+`project-name` は、Launchpad上のプロジェクトIDです。以下にいくつか例を挙げます。::
+
+ bzr branch lp:inkscape
+ bzr branch lp:amarok
+ bzr branch lp:python
+ bzr branch lp:rails
+ bzr branch lp:java-gnome
+
+そのあと、好きなエディタやIDEを使って、コードを手元で参照したり、必要があれば編集したり\
+することができます。
+
+もし、プロジェクトに複数のシリーズ(例えば、開発用とメンテナンス用)が登録されている場合は、\
+以下のコマンドで指定したシリーズの最新のコードを取得することができます。::
+
+ bzr branch lp:project-name/series
+
+変更内容の公開
+-----------------------
+
+イライラするバグを修正したり、ずっと欲しかったクールな機能を追加したりしたら、それを友達に\
+アピールしたり、そのコードを他の人に公開して世の中をもっと良くするときです。
+これまでに説明したとおり、LaunchpadはBazaarによる無料のコードホスティングサービスなので、自分の\
+ブランチをプッシュして他の人がそこからコードにアクセスできるようにすることができます。
+例えば、あなたが関連するチームのメンバーだとすると、以下のようにLaunchpadにログインします。::
+
+ bzr launchpad-login userid
+
+`userid` は、LaunchpadのユーザIDです。
+そのあと、以下のように変更をチームのブランチにプッシュすることができます。::
+
+ bzr push lp:~team-name/project-name/branch-name
+
+他の人は、以下のようにそのコードをダウンロードすることができます。::
+
+ bzr branch lp:~team-name/project-name/branch-name
+
+
+自分用のブランチ
+-----------------
+
+あなたがチームのメンバーではなかったとしても、Launcpadであなたの変更内容を公開することができます。
+この場合、以下のようにして単純に自分用のブランチを作成します。::
+
+ bzr push lp:~userid/project-name/branch-name
+
+他の人は、以下のようにそのコードをダウンロードすることができます。::
+
+ bzr branch lp:~userid/project-name/branch-name
+
+Note: 自分用のブランチに公開したときも、ちゃんと上流の開発者にあなたのブランチについて通知されるので、\
+全てのユーザに一般的に適用できる内容で、かつプロジェクトの品質基準を満たしていれば、彼らはその変更を\
+プルすることができます。
+
+.. Package source branches
+
+パッケージのソースブランチ
+-----------------------------
+
+`maintaining packages for Ubuntu using Bazaar` に書かれているとおり、
+Launchpad から簡単にパッケージのソースブランチにアクセスできます。
+現在の(デフォルトの)系列のパッケージのソースブランチは、次のようなコマンドで
+ダウンロードできます。 ::
+
+ bzr branch ubuntu:package
+
+ここで、 *package* はアクセスしたい Ubuntu のパッケージ名です。
+Ubuntu の特定の系列 (例: Maverick, Lucid) のパッケージブランチを
+ダウンロードするには、次のコマンドを使います。 ::
+
+ bzr branch ubuntu:maverick/package
+
+Ubuntu の系列は単に最初の文字を使う形に省略することができます。
+たとえば、上の例は次のようにも書けます。
+
+ bzr branch ubuntu:m/package
+
+いくつかの Debian の系列でも、 Launchpad からソースブランチをダウンロードする
+ことができます。デフォルトの系列であれば次のようにダウンロードできます。 ::
+
+ bzr branch debianlp:package
+
+そして、特定の系列の場合は次のようになります。 ::
+
+ bzr branch debianlp:lenny/package
+
+``debianlp:`` スキーマは Launchpad にある Debian のソースブランチにしか
+アクセスできないので注意してください。
+
+.. _`maintaining packages for Ubuntu using Bazaar`: https://wiki.ubuntu.com/DistributedDevelopment
+
+
+Lanchpadでのブランチの関連づけ
+===============================
+
+ブランチをバグと関連付ける
+-------------------------------
+
+ブランチを登録したあと、それにバグを関連づけることができます。
+そうすることで、そのバグに関心をもつ人々がそのブランチを追いかけ、修正が公開されたらダウンロード\
+することができます。
+
+そのための手順は以下のとおりです。
+
+1. Questionから、そのバグに移動します。
+
+2. `Actions` から `Add branch` を選択します。
+
+3. ブランチを選択します。
+
+4. 必要に応じて、関連づけのステータスを設定します。
+ *Fix In Progress(修正中)* がデフォルトですが、すでにブランチ内にで問題に対処しているのなら、\
+ *Fix Available(修正済)* に設定することもできます。
+
+もし望むのなら、バグとブランチとの関連づけに好きなコメントをつけることもできます。
+
+BazaarでのコミットによるLaunchpadのステータスの変化
+----------------------------------------------------------
+
+BazzarとLaunchpadを一緒につかうことで、ステータスのメンテナンス作業をへらすことができます。
+Bazaarでコミットしたときに、以下のように--fixesオプションを指定します。::
+
+ bzr commit --fixes lp:1234 -m "..."
+
+この1234というのはバグIDです。こうすると、バグ-ブランチ間の関連づけのステータスが *Fix Available* \
+に変わります。
+一回のコミットで複数の問題を修正する場合には、--fixesオプションを複数回指定できます。
+
+この機能のすばらしい点のひとつは、コミットするときにLaunchpadにアクセスできなくてもいいということです。
+``--fixes`` オプションではメタデータを保存し、次にそのブランチがLaunchpadにプッシュされたときか、\
+オンラインで再スキャンされたときに、Launchpadはそのメタデータを検出します。
+
+Note: Launchpadは、ブランチでバグが修正されたからといって勝手にバグをクローズすることはありません。
+これにはいくつかの理由があります。
+一つ目の理由は、ほとんどのチームでは、たいていブランチをトランク(メインの開発ブランチ)にマージしないと\
+バグが修正されたとはみなさないためです。
+二つ目の理由は、多くのチームでは、バグが修正されたことを確認するためには、「開発者がそう言っている」と\
+いうだけではなくそれ以外のプロセスがあるためです。
+
+あとで説明しますが、マージ管理機能が現在Launchpadで開発されており、この機能がリリースされれば、バグの\
+ステータスを *Fix Committed* に自動変更する機能がもっと適切なものになります。
+
+
+ブランチをブループリントと関連づける
+-------------------------------------
+
+ブランチを登録したあと、それにブループリントを関連付けることができます。
+そうすることで、そのブループリントに関心を持つ人々がそのブランチを追いかけ、開発中の新機能をテストする\
+ことができます。
+
+そのための手順は以下の通りです。
+
+1. Questionから、そのブループリントに移動します。
+
+2. `Actions` から `Link branch` を選択します。
+
+3. ブランチを選択します。
+
+もし望むのなら、ブループリントとブランチとの関連づけに好きなコメントをつけることもできます。
+
+
+Launchpadをつかったリリースの管理
+=================================
+
+変更内容の統合
+-------------------
+
+ブランチが開発され、公開されたら、コミュニティでは一般的に、その変更内容をコアプロダクトに統合して\
+エンドユーザにリリースする前に厳格なプロセスを通します。
+その中には、以下のような手順が含まれるでしょう。:
+
+* 仲間による変更内容のレビュー
+
+* どのリリースにその変更を含めるかの決定。たとえば、次のメンテナンスリリース、次のメジャーリリース、\
+ もしくはその両方。
+
+* 機能の回帰テストの実行
+
+* パフォーマンスが基準を満たすかどうかを確認するためのベンチマーキング
+
+* エンドユーザテストのための早期提供リリースの作成
+
+* ドキュメントの更新。たとえば、そのリリースのためのリリースノートなど
+
+* ユーザインターフェイスやドキュメントの他言語への翻訳
+
+このセクションでは、プロダクトのコードの品質を高めるために役立つLaunchpadの機能のいくつかについて簡単に\
+説明します。
+Bazaarとの強力な一体化が、それをスムーズにするためのポイントです。
+
+Note: 以下にあげる機能の中には、まだ開発中のものもあります。
+もし、これらの機能に興味があるのなら、以下のリンクでLaunchpadベータテストチームへの参加を検討してください。:
+https://help.launchpad.net/JoiningLaunchpadBetaTesters
+そうすれば、各機能の早期提供版を手に入れて、広くリリースされる前に開発者にフィードバックを送ることができます。
+
+
+ブランチのマージの提案
+-----------------------
+
+Launchpadでブランチに移動したあとに実行できるアクションのひとつに、 *Propose for merging(マージの提案)*
+があります。
+この機能では、どのブランチがこのコードを取り入れるべきかを指定します。
+
+どのブランチがコードラインへのマージ提案中なのかという情報を追跡することは、リリース管理者が、\
+リリース日までに何を完了させなければならないか、または何を完了させることができるかを常に把握するために役立ちます。
+この情報をもとに、必要なレビューを実行してからブランチをマージすることを確実に行うことができます。
+単純なケースでは、リリース管理者は手作業でブランチをマージします。
+もっと高度なケースでは、ブランチがあるべきステータス(たとえば、 *Review completed(レビュー完了)*)になった\
+ときにロボット(`PQM`_ のような)に自動的にマージさせることができます。
+
+.. _PQM: https://launchpad.net/pqm
+
+
+コードレビューの追跡
+----------------------
+
+コードレビューの状態や会話の内容、成果物を追跡するために、Launchpadでたくさんの機能が開発されています。
+これらの機能は、ブランチのマージ提案やブランチ閲覧の機能に統合されると思われます。
+
+
+パーソナルパッケージアーカイブ(PPA)
+------------------------------------
+
+PPAは、開発者や開発チームが、早期提供版でテストとフィードバックを行うユーザにカスタムビルドモジュールを渡す\
+手助けをします。
+言い方を変えると、PPAによって、開発者はその変更内容に関心を持つテスターのコミュニティを結成することが\
+できるようになります。
+テスティングコミュニティは、パッケージをインストールし、テスト期間中にそれを実行し、その後はシステムから\
+きれいに削除することができます。
+
+より詳細な情報は、 https://help.launchpad.net/PPAQuickStart を参照してください。
+
+
+翻訳
+------------
+
+Launchpadの翻訳モジュールは、誰もがアプリケーションを自分が知る言語に簡単に翻訳できるように設計されています。
+翻訳者は、深いレベルの詳細を知る必要はありません。
+
+Launchpadは、プロジェクトの各メジャーバージョンに対する翻訳を別々に記録するので、だれかが新しい開発バージョンの\
+作業を始めていても、安定版の翻訳の改良を続けることができます。
+プロジェクトをまたがってリソースを共有することにより、翻訳のスピードを短縮しています。
+75万件の翻訳済みのテキストのライブラリからの自動抽出機能と、1万9千人の翻訳者のコミュニティとが、プロジェクトを\
+多くの言語に翻訳する時間を短縮してくれます。
+
+.. XXX Translation speed in reduces by sharing resources across projects. > in は isの間違いだと思われる。
+
+要約
+=======
+
+私たちが参加するコミュニティは、それがオフラインであれオンラインであれ、私たちがどのような種類の人間であるかを\
+表すものです。
+逆に言うと、あなたがコミュニティのために選ぶツール - 特に、CDEとバージョン管理ツール - は、誰がそのコミュニティ\
+に参加するのかということ、また、その人たちがどれだけ簡単にコミュニティに貢献できるかということに大きな影響を与えます。
+
+LaunchpadとBazaarは、単独でもとても役に立つツールです。
+一緒に使えば、以下のことが可能になります。:
+
+* コミュニティの、ソースコードやナレッジのような資産の追跡を助ける。
+* コミュニティへの参加の妨げを軽減して、コミュニティの成長を促す。
+* 関係するコミュニティとのやりとりを助ける。
+
+具体的には、LaunchpadはあなたのBazaarブランチを管理する無料のコードホスティングサービスであり、ブランチをオンラインで\
+閲覧でき、ブランチとバグやブループリントを関連づけることができ、Bazaarへのコミット時にバグについて記述することによって\
+ブランチ-バグ間のステータスを自動的に変更することができます。
+*すばらしいアイデア* を、 *エンドユーザの元で実行されるコード* にするまでのプロセスを合理化するための、より進んだ統合\
+機能が現在開発中です。
+
+もし、BazaarとLaunchpadがさらにどのように統合されてほしいかについて、何かフィードバックすることがあるのなら、\
+Bazzarメーリングリストで私たちに連絡してください。
+bazaar@lists.canonical.com.
+
+Launchpadは自由ソフトウェアプロジェクトをサポートするための無料のサービスとしてデザインされていますが、Canonicalはこれを\
+商業ソフトウェアの開発者にも、その要望次第で提供することができます。
+オープンソースであってもなくても、Launchpadがあなたのコミュニティの運営に役立つと考えていただけるのならば幸いです。
+
diff --git a/doc/ja/upgrade-guide/data_migration.txt b/doc/ja/upgrade-guide/data_migration.txt
new file mode 100644
index 0000000..aa4bf89
--- /dev/null
+++ b/doc/ja/upgrade-guide/data_migration.txt
@@ -0,0 +1,132 @@
+データ移行
+###############
+
+データ移行の準備
+-------------------
+
+移行を開始する前に、最初におこなうべきことがあります。
+
+1. 完全にバックアップをとってください。
+
+2. 古いブランチを消去(purge)する時間をとってください。
+
+完全なバックアップはなにか悪いことがおきたときのセーフティネットとなります。
+
+古いブランチの消去は移行対象となるデータを減らすことができます。これをおこなうためのいくつかのコツを
+`Finding obsolete branches`_  でご覧ください。
+
+移行に関連するコマンドの紹介
+----------------------------------
+
+データ移行時には注意すべき3つの重要なコマンドがあります。
+
+* **check** - リポジトリ、ブランチやツリーのデータ完全性に関するエラーのチェック。
+
+* **reconcile** - データ完全性に関するエラーの修復。
+
+* **upgrade** - 異なるデータフォーマットへの移行。
+
+**reconcile** はめったに必要ではありませんが **check** を **upgrade** の前後で行うことは良い習慣です。
+
+これらのコマンドの詳細なヘルプは `Bazaarユーザーリファレンス`_ をごらんください。
+
+.. _Bazaarユーザーリファレンス: ../user-reference/index.html
+
+
+あなたのコミュニティとのコミュニケーション
+---------------------------------------------------------
+
+新しいフォーマットへのスムーズな移行を可能にするためには、以下が必須です:
+
+1. trunkの移行を行う責任者を1人きめること。
+
+2. trunkの移行試験が成功すること。
+
+3. trunkを移行する時間の予定をたてることと、前もってあなたのコミュニティに知らせておくこと。
+
+事前に警告をしておくことによりコミュニティに所属する人々が 移行日より前に Bazaarや必要なpluginを移行するのに十分な余裕を持つことができるでしょう。
+
+さらに大きなコミュニティにおいては、移行それ自身に要する時間に配慮しましょう。
+試験移行の後でどのくらい移行に時間がかかるのかに関する良い案を持っておくべきです。移行を週末か金曜日に行うことで問題が発生したときにあなた自身が一息つける時間をとることができることは道理にかなっているでしょう。
+
+trunkが移行したら、あなたはコミュニティに対して適切にお知らせし、彼らに彼ら自身のローカルブランチの移行説明書を示す必要があります。後ほど説明書の例を示します。
+
+
+スタンドアロンブランチの移行
+------------------------------------
+
+作業手順は以下のとおりです。:
+
+1. **bzr check** を起動します。
+
+2. もしエラーが発生したら、**bzr reconcile** を使ってエラーの修復をこころみてください。もしこれが失敗したら問題を解決してあなたのtrunkをクリーンにするために私たちがお手伝いできるようバグの報告ください。もし成功したならクリーンなtrunkなうちにバックアップをとってください。
+
+3. **bzr upgrade --format** を実行してください。**format** は 2a またはそれ以降のことです。
+
+4. **bzr check** を起動して最終結果が正しいかどうかを確認してください。
+
+
+共用リポジトリ中のブランチを移行
+-----------------------------------------
+
+移行は以下の手順で行ってください:
+
+1. 共用リポジトリの移行。
+
+2. ブランチの移行。
+
+3. 軽量チェックアウトの移行。
+
+スタンドアロンブランチの例のように **check** を移行の前後に行って問題が存在していないか、あるいは問題がひきおこされていないかを確認してください。
+
+
+Launchpad上のブランチを移行
+-------------------------------
+
+公開ブランチとプライベートブランチを独立させるために、Launchpadでは共用リポジトリではなく、スタックブランチをディスク容量の効率化の中心技術として使用しています。したがってLaunchpadをコードホスティングに使用しているプロジェクトでは新しいフォーマットへの移行は個人や社内でしようしているとはことなります。
+
+手順は次のようになります:
+
+1. 指名された人がtrunkのコピーを持ち移行作業を実施します。
+
+2. Launchpadにおいては 現在のtrunkを開発の中心(focus)からはずします。(これは *必ず* 実施してください、そうしないとこの後の手順が期待通りになりません。)
+
+3. 移行した trunk をLaunchpadに push します。
+
+4. 開発の中心(focus)に設定します。
+
+5. 古い trunk に登録しているユーザに対して新しい trunk へ登録するよう依頼します。
+
+つまり、これらの手順の意味は 古い trunk がいぜんとして有効でスタックされたブランチが存在し続けるということです。しかしながら開発の中心は移行後の trunk に切り替わっており、以後のLaunchpadにpushされるあなたのプロジェクトの新しいブランチは(移行後のtrunkに)スタックされます。
+
+この時点であなたはあなたのコミュニティに対して 新しいtrunkが有効になったことを知らせ、彼らに彼らのローカルブランチを移行する説明する準備ができました。
+
+
+中央の trunk が移行した後のローカルブランチ移行
+-----------------------------------------------------------
+
+スタンドアロンブランチの移行手順:
+
+1. 中央リポジトリの場所から最新のブランチを新しいディレクトリに取得します。
+
+2. 既存のブランチの中のあなたが行った修正を新しいブランチへpullあるいはmergeします。
+
+ブランチを共用リポジトリに移行する手順:
+
+1. 新しい共用リポジトリを新フォーマット(2aあるいはそれ以降)で作成します。
+
+2. 中央リポジトリから最新のブランチを作成した共用リポジトリへ格納します。
+
+3. あなたのローカルブランチで移行したいものを決定します。
+ (もし決定していなければ、もちろんバックアップした後、
+ `Finding obsolete branches`_ をしてそのブランチを消去するのによい時間です。)
+
+4. 各ローカルブランチの移行に関して2つ選択肢があります。
+
+ * 新しいリポジトリで1つ空のブランチを **init** して古いリポジトリからリビジョンを **pull** する。
+
+ * 新リポジトリにおいて、 trunkから新しいブランチに **branch** した後古いリポジトリにおいてあなたが行った変更を **merge** する。
+
+前者の方法は(リビジョンの履歴という意味において)古いブランチと同一のブランチを得ることができる一方、parentブランチは古いブランチを指してしまい、新しいtrunkをさしません。もしあなたがこの方法をとった場合、おそらく branch.conf ファイルの parentブランチに関する設定をしなおしたくなるでしょう。
+
+それに比較して後者の方法は parentブランチは正確に設定されます。しかし、もしあなたがすべての最新のリビジョンをtrunkからそのブランチにincludeする用意ができていない限り理想的な方法にはなりません。
diff --git a/doc/ja/upgrade-guide/index.txt b/doc/ja/upgrade-guide/index.txt
new file mode 100644
index 0000000..a38c445
--- /dev/null
+++ b/doc/ja/upgrade-guide/index.txt
@@ -0,0 +1,13 @@
+###########################
+Bazaar 2.0 移行ガイド
+###########################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+.. include:: overview.txt
+.. include:: data_migration.txt
+.. include:: tips_and_tricks.txt
diff --git a/doc/ja/upgrade-guide/overview.txt b/doc/ja/upgrade-guide/overview.txt
new file mode 100644
index 0000000..e3dd062
--- /dev/null
+++ b/doc/ja/upgrade-guide/overview.txt
@@ -0,0 +1,77 @@
+概要
+########
+
+移行手順の概要
+----------------
+
+Bazaar 2.xへのアップグレード作業は3段階あります:
+
+1. コアソフトウェアの移行
+
+2. 必要なプラグインの移行
+
+3. 新しいデフォルトフォーマットへのデータ移行
+
+Bazaar 2.xは以前のブランチのフォーマットをサポートしているので、厳密には3番目の手順は
+必要ありません。しかし、Bazaar 2.xの新しいデフォルトフォーマットはより効率よく領域を使用する、
+巨大なプロジェクトでより高速になる、さまざまな新しい特徴をそなえている、などの理由からほとんどのプロジェクトについて都合のよいときにでもアップグレードすることをおすすめします。
+
+ほとんどのユーザの方は2.xへのアップグレードと新しいフォーマットへの移行に苦労しません。
+しかしながら、大勢の開発者がいる(もしくは多くの開発者をようする)プロジェクトでは移行作業に手間がかかります。
+この場合、注意深く計画をたてることとよいコミュニケーションが必要不可欠となります。
+本文書はこの視点からの一般的なアドバイスを記載しています。
+不安な点がありましたら、メーリングリストやIRCチャンネルで私たちにおたずねください。
+
+
+コアソフトウェアの移行
+-----------------------
+
+コアソフトウェアの移行手順はオペレーティングシステムによって異なります。
+Bazaar 1.xからBazaar 1.yへの移行とBazaar 1.xからBazaar 2.0への移行には特に違いはありません。手順の概要は以下のようになります。
+
+Linuxでの移行手順:
+
+1. 必要なソフトウェアのソースに関してお使いのパッケージマネージャの設定をおこなう。
+ たとえばUbuntuの正式なリリースのPPAは https://launchpad.net/~bzr/+archive です。
+
+2. パッケージマネージャを使用して最新バージョンに移行する。
+
+Windowsでの移行手順:
+
+1. 「プログラムの追加と削除」で古いバージョンを削除する。
+
+2. 新しいバージョンのインストーラでインストールする。
+
+OS Xでの移行手順(インストーラを使用):
+
+1. 新しいバージョンのインストーラでインストールする。
+
+OS Xでの移行手順 (MacPortを使用):
+
+1. package metadataを更新する。 **sudo port selfupdate**
+
+2. 最新のバージョンに更新する。 **sudo port upgrade bzr**
+
+インストールや移行に関する詳しい情報については http://bazaar-vcs.org/Download
+をごらんください。
+
+必要なプラグインの移行
+-----------------------
+
+多くのプラグインは特定のBazaarのバージョンに依存していないので、任意の作業です。
+他のプラグイン、特にbzrtoolsとbzr-svnはBazaarのAPIにかたく結びついているので、
+大体はコアソフトウェアとあわせて移行する必要があります。
+
+WindowsやOS Xをお使いのかたは、bzrtoolsとbzr-svnはインストーラに付属していますので
+移行にあたって特別な作業は必要ありません。LinuxやUNIXをお使いのかたは、bzrtools、bzr-svn
+や他の著名なプラグインをインストールしたり移行作業をお使いのプラットホームのパッケージマネージャ
+(たとえばUbuntuのSynaptic)でおこなうことができます。
+
+
+新しいデフォルトフォーマットへのデータ移行
+-------------------------------------------
+
+冒頭でも説明しましたように新しいフォーマットへの移行に伴う複雑さはいくつかの要因、特にプロジェクトの
+コミュニティの大きさに依存します。また、データがどのように保存されているかにも依存します。たとえば
+standaloneブランチとか、複数のブランチがshared repositoryに格納されているかとか、Launchpad上の
+stackedブランチかなどです。これらのシナリオについては次章で説明します。
diff --git a/doc/ja/upgrade-guide/tips_and_tricks.txt b/doc/ja/upgrade-guide/tips_and_tricks.txt
new file mode 100644
index 0000000..a62e911
--- /dev/null
+++ b/doc/ja/upgrade-guide/tips_and_tricks.txt
@@ -0,0 +1,23 @@
+役立つヒントとコツ
+######################
+
+古いブランチを見つける
+-----------------------------
+
+もしあなたが開発における各変更や個々に行っている拡張のためにブランチの機能を使っている場合、いくつかのもう必要とされないブランチを持つことになるかもしれません。たいていの場合、関係のある変更は trunkにマージされているはずです。そのほかの場合ブランチは自分あるいは他人が行った別の変更の結果、古くなっているはずです。
+
+古いブランチをチェックするときには特に3つの点に注意があります。
+
+1. ワーキングツリーは変更の途中でないこと。
+
+2. ワーキングツリー内にはbzr shelveコマンドによって退避された変更をふくんでいないこと。
+
+3. どんなローカルでコミットされたリビジョンもparentブランチにマージされていること。
+
+ブランチのルートディレクトリに移動したあと、これらの点を個々にチェックするためのコマンドは以下です::
+
+ bzr status
+ bzr shelve --list
+ bzr missing --mine-only
+
+もしあなたのブランチがローカルの共用リポジトリに入っているならば、(revision 159またはそれ以降の)Bazaar Explorerのリポジトリビューの中の *Local Changed* タブがあなたが選択したブランチについて、いまのところはshelveコマンドによって退避された変更を除き、上記の情報の概要を表示するので有用です。
diff --git a/doc/ja/user-guide/adv_merging.txt b/doc/ja/user-guide/adv_merging.txt
new file mode 100644
index 0000000..a59042e
--- /dev/null
+++ b/doc/ja/user-guide/adv_merging.txt
@@ -0,0 +1,130 @@
+疑似マージ
+===========
+
+チェリーピッキング
+------------------
+
+時々、ブランチの変更の全部ではなく一部だけを選んでマージすることが\
+便利であることがあります。
+これは一般的に *チェリーピッキング(cherrypicking)* として言及されます。
+
+チェリーピッキングが役に立ついくつかの事例:
+
+* メインの開発ブランチから修正の一部を取り出してリリースブランチに取り込む
+
+* 実験ブランチから改善内容を選別して機能ブランチに取り込む
+
+``foo`` ブランチのリビジョン Xによってなされた変更のみをマージするためには::
+
+ bzr merge -c X foo
+
+``foo`` ブランチのリビジョンXまでの変更のみをマージするためには::
+
+ bzr merge -r X foo
+
+``foo`` のリビジョンX以降の変更のみをマージするためには::
+
+ bzr merge -r X.. foo
+
+``foo`` ブランチのリビジョンXからリビジョンYまでの変更のみをマージするには::
+
+ bzr merge -r X..Y foo
+
+通常のマージと同じように、チェリーピックは明示的にコミットしなければなりません。
+これを行う前に、 ``bzr diff`` を利用した変更を見て何かあればテストスイートを\
+実行するとよいでしょう。
+
+通常のマージとは異なり、Bazaarは現在はチェリーピックを追跡しません。
+具体的に言うと、変更は通常のコミットと同じようになり、他のブランチから来た(内部の)変更履歴は失われます。
+上記のようなチェリーピックが役に立つ場面では、このことはたいてい重大な問題ではありません。
+フルマージが後で行われることはけっしてないと言える十分な理由があるからです。
+そうではない場面では、変更が再びマージされたときにまた衝突を解消する必要があります。
+
+.. Merging without parents
+
+親のないマージ
+------------------
+
+チェリーピックに関連したテクニックとして、マージ元のリビジョンを参照せずに、
+コミット前に親リビジョンを忘れることができます。
+こうすると、このマージで行われた全ての変更が、1回のコミットで行われたような
+効果があります。
+マージしたあと、コミットする前に次のコマンドを実行します。 ::
+
+ bzr revert --forget-merges
+
+これで、作業ツリー内の変更は残したまま、その変更がどこからマージされたかの
+記録だけを削除します。そして、次のコミットではマージされたリビジョンに
+関する情報が一切ない状態で、全ての変更を記録します。
+
+この機能は、「きれいな」履歴を作りたいユーザーに取って便利なものですが、
+Bazaarはもともとマージされた履歴を段階的に表示する機能を持っているので、
+失った履歴の価値が履歴のきれいさの価値を上回らないように気をつける必要があります。
+特に、この機能を使うとマージ元の変更だけを取り込んでその変更のマージ元を
+記録しないので、後で同じマージ元からマージしようとすると余計なコンフリクトを
+発生させる可能性があります。
+
+
+.. _reverse-cherrypicking:
+
+リバースチェリーピッキング
+---------------------------
+
+チェリーピッキングは一連の変更を元に戻すことができます。この場合、リビジョン範囲の\
+上界(upper bound)が下界(lower bound)よりも *小さく* なります。
+たとえば、リビジョン10の変更を取り消すためのコマンドはこうなります::
+
+ bzr merge -r 10..9
+
+どこかから、すべてではない大半の変更を得たい場合通常のマージをした後に少しの\
+リバースチェリーピックを行うとよいでしょう。
+
+
+コミットされていない変更をマージする
+-------------------------------------
+
+複数のブランチを持っており、間違えて別のブランチを変更し始めた場合、訂正をとるステップは次のとおりです。
+ブランチ ``bar`` で作業したかったのに、ブランチ ``foo`` で作業を始めてしまったという場合を前提とします:
+
+1. ``bar`` ブランチに移動する
+2. ``bzr merge --uncommitted foo`` を実行する
+3. やってくる変更をチェックする (``bzr diff``)
+4. ``foo`` ブランチに変更する
+5. ``bzr revert`` を実行する
+
+.. TODO Selective file merging?
+
+
+リベースする
+--------------
+
+通常のマージの別のオプションは *リベース(rebase)* です。
+すなわち、現在のブランチが本来とは異なる地点をベースにするようにします。
+リベースは ``rebase`` プラグインによって提供される ``rebase`` コマンド\
+によってサポートされます。
+
+``rebase`` コマンドは現在の作業ディレクトリ内のリベースされるブランチ上で\
+別のブランチの位置をとります。
+ブランチが指定されないと親のブランチが使われ、通常これは望まれる結果です。
+
+最初のステップは現在のブランチのものであるが親のブランチではないリビジョンを\
+特定することです。
+現在のブランチはターゲットブランチと同じリビジョンに設定され、それぞれの\
+リビジョンはブランチのトップで再現されます。
+プロセスの終了時に現在のブランチがターゲットの最終リビジョンからブランチ\
+されたようになります。
+
+再現されるそれぞれのリビジョンがツリーの中で衝突を起こすことがあります。
+これが起きたらコマンドは停止してそれらを修正しなければなりません。
+``merge`` するためにコミットを解消し、それらが解消されたものとしてマークするために
+``bzr resolve`` を実行します。
+すべての衝突を解消したら、リベースオペレーションを続けるために ``bzr rebase-continue``
+を実行します。
+衝突に遭遇せず続けないことを決めたら、 ``bzr rebase-abort`` を実行できます。
+リプレイされるコミットの一覧を表示するために ``rebase-todo`` を利用することもできます。
+
+注: マージトラッキング機能が貧弱なVCSツールから来たユーザーの中にはリベースを好む人がいます。
+古いツールでの作業方法に似ている、もしくは"完璧にきれいな" 履歴が重要だからです。
+Bazaarでリベースする前に、通常のマージがベターな選択肢ではないのか考えてください。
+とりわけ、始める前にプライベートなブランチをリベースするのは大丈夫ですが、
+他の誰かとブランチを共有した後のリベースは **強く非推奨** です。
diff --git a/doc/ja/user-guide/annotating_changes.txt b/doc/ja/user-guide/annotating_changes.txt
new file mode 100644
index 0000000..026264c
--- /dev/null
+++ b/doc/ja/user-guide/annotating_changes.txt
@@ -0,0 +1,34 @@
+変更に注釈を付ける
+===================
+
+内容の起源を探し出す
+--------------------
+
+複数の人がファイルに取り組むとき、
+誰が作ったのかもしくは最後に変更された内容を一度に見ることができるのは非常に便利です。
+これを行うためには、annotateコマンドを使います::
+
+ bzr annotate readme.txt
+
+悲観主義者もしくは楽観主義者のどちらかであるなら、
+``annotate`` の組み込みのエイリアスである ``blame`` もしくは ``praise``
+を使うことを好むかもしれません。
+どの方法であれ、次のような情報と一緒にファイルのそれぞれの行が表示されます:
+
+ * 最後に変更した人
+ * 最後に変更した時間
+ * コミットメッセージ
+
+GUIツール
+----------
+
+Bazaar用のさまざまなGUIは注釈の情報を閲覧するためのグラフィカルなツールを提供します。
+たとえば、bzr-gtkプラグインはこの機能を ``gannotate`` コマンドを使用して起動できる\
+GUIツールとして提供します::
+
+ bzr gannotate readme.txt
+
+GUIツールは関心のある情報をより豊かに表現するので
+(たとえばそれぞれのコミットのすべての変更内容)、\
+テキストベースよりも好ましいかもしれません。
+
diff --git a/doc/ja/user-guide/bazaar_workflows.txt b/doc/ja/user-guide/bazaar_workflows.txt
new file mode 100644
index 0000000..40253b7
--- /dev/null
+++ b/doc/ja/user-guide/bazaar_workflows.txt
@@ -0,0 +1,181 @@
+ワークフロー
+=============
+
+Bazaarはただのツール
+---------------------
+
+Bazaarは多くの異なる共同作業の方法を支援します。
+このことはあるワークフローで始めて状況が変われば別のワークフローを\
+採用できることを意味します。
+"唯一の正しい方法"は存在しませんし今後も現れることはりません。
+このセクションではBazaarによってサポートされる人気のあるいくつかの\
+ワークフローの手短な概要を提供します。
+
+これらのワークフローはBazaarの使い方の *一部* であることを念頭にお願いします。
+ここに記載されていないワークフローを利用したいのであれば、\
+下記に記載されているアイディアを足場にします。
+
+ソロ
+----
+
+ソフトウェアを開発する、ドキュメントを編集するもしくは設定ファイルを\
+変更するのであれ、簡単に使えるVCSは手助けになります。
+投稿者が1人であるプロジェクトを複数管理するために\
+単独のユーザーはこのワークフローを効率的に利用できます。
+
+.. image:: images/workflows_single.png
+
+まったくバージョン管理を使わない場合と比べたこのワークフローの利点は次のとおりです:
+
+ * 古いバージョンのバックアップ
+ * 前の状態へのロールバック
+ * 履歴の追跡
+
+このワークフローに適切なBazaarの主要な機能は管理作業が少ない\
+(サーバーのセットアップは不要)ことと簡単に利用できることです。
+
+
+パートナー
+-----------
+
+時に2人で変更を共有して共同作業をする必要があります。
+これは一般的に *ソロ* のワークフロー (上記を参照) もしくは\
+チーム指向のワークフロー(下記を参照)として始まります。
+ある時点で、2人目の人が最初の人が行った内容(履歴も含む)を含む\
+ブランチを作ります。
+適切なときにマージして変更内容を交換することで並行して作業できます。
+
+.. image:: images/workflows_peer.png
+
+*ソロ* を上回る利点は次のとおりです:
+
+ * 変更の共有が簡単
+ * それぞれのテキストファイルのそれぞれの行は変更した人、\
+ 時間と理由を含む特定の変更と結びつけられています。
+
+このワークフローを採用する場合、BazaarはCVSとSubversionに対して
+次のような利点があります:
+
+ * サーバーのセットアップが不要
+ * インテリジェントなマージ機能により複数回のマージ作業が苦痛では
+ なくなります。
+
+
+集中型
+-------
+
+*lock-step* としても知られますが、これはCVSとSubversionによって\
+推奨/強制されるワークフローと本質的に同じです。
+すべての開発者が同じブランチに取り組みます。
+最新の内容をチェックアウトするために ``bzr update`` を実行し、\
+変更内容を中心位置にコミットするために ``bzr commit`` を実行します。
+
+.. image:: images/workflows_centralized.png
+
+このワークフローを導入するのであればSubversionとCVSも簡単なのでよい選択肢です。
+Bazaarはこのワークフローも直接サポートしていて、CVSとSubversionを上回る利点を\
+いくつかもちます:
+
+ * よりよいブランチとマージ
+ * よりよいリネームのサポート
+
+
+ローカルなコミットで集中型
+---------------------------
+
+このワークフローは、開発者が ``commit --local`` もしくはチェックアウトをunbind\
+して一連の変更を行うこと以外は、 *集中型* モデルと基本的に同じです。
+こういった一連の変更が完了するとき、開発者は作業内容を共用のメインラインに\
+コミットします。
+
+.. image:: images/workflows_localcommit.png
+
+*集中型* を越える利点:
+
+ * 旅行の間にネットに接続していないなどのオフラインで作業できます
+ * 誰かの作業を妨げる良くないコミットをする機会が少なくなります
+
+SubversionとCVSはこのモデルをサポートしません。
+他の分散型VCSツールはこれをサポートしますが、Bazaarよりも直接的ではありません。
+
+
+共用のメインラインで分散型
+-----------------------------
+
+このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
+加えてメインブランチにコミットする権限があります。
+開発者は個人のブランチに取り組み、準備ができたらそれをメインラインに\
+マージします。
+
+.. image:: images/workflows_shared.png
+
+*ローカルコミットつきの集中型* を越える利点は次のとおりです:
+
+ * 作業内容の編成が簡単になる - それぞれのブランチで個別の変更を開発できます。
+ * 開発者は共同作業に取り組むときに別の人の個人ブランチをマージできます。
+
+SubversionとCVSはこのモデルをサポートしません。\
+他の分散型VCSツールはサポートします。
+Bazaarの多くの機能は、簡単な利用、共用レポジトリ、統合されたマージ機能と\
+リッチなメタデータ(ディレクトリのリネームの追跡を含む)を\
+含めてこのワークフローに有効です。
+
+人間のゲートキーパーで分散型
+-----------------------------
+
+このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
+それに加えてメインのブランチに対してリードオンリーのアクセス権限を持ちます。
+1人の開発者(ゲートキーパー)はメインのブランチにコミットする権限を持ちます。
+1人の開発者が彼らの作業をマージしたい場合、ゲートキーパーに\
+マージしてくれるように頼みます。
+ゲートキーパーはコードのレビューを行い、必須の基準を満たすのであれば\
+作業内容をメインブランチにマージします。
+
+.. image:: images/workflows_gatekeeper.png
+
+*共用のメインラインによる分散型* に対する利点は次のとおりです:
+
+ * 常にコードはメインラインに入る前にレビューされます。
+ * 変更をメインラインに組み込むときに厳格なコントロールができます
+
+Bundle Buggyと呼ばれるBazaarのコンパニオンツールはどんな変更が\
+レビュー待ちになっているのか、その変更のステータスとレビューアの\
+コメントを追跡するのにとても便利です。
+
+
+自動的なゲートキーパーで分散型
+-------------------------------
+
+このワークフローにおいて、それぞれの開発者は独自のブランチを持つのに加えて、\
+メインストリームにリードオンリーのアクセス権限を持ちます。
+ソフトウエアのゲートキーパーはメインのブランチにコミットする権限を持ちます。
+開発者が作業内容をマージしたいとき、開発者は別の人にレビューを頼みます。
+レビューに合格したら、チームの方針によって、オリジナルの著者もしくは
+レビューワがゲートキーパーソフトウェアにマージするように頼み、
+ゲートキーパーソフトウェアはマージし、コンパイルし、テストスィートを実行します。コードがパスする場合のみ、メインラインにマージされます。
+
+注: 代替として、レビューのステップをスキップして著者は変更を自動化された\
+ゲートキーパーに投稿できます。
+(これはコードのレビューを別のステップとしてではなくジャストインタイムの\
+レビューを効果的に推進するペアプログラミングといった習慣を利用している\
+ときにとりわけ適切です。)
+
+.. image:: images/workflows_pqm.png
+
+*人間のゲートキーパーによる分散型* に対する利点は次のとおりです:
+
+ * コードはメインラインに入る前に常にテストされます
+ (メインラインの完全性が高まります)
+ * チームの規模の成長に対応できます
+
+BazaarのコンパニオンツールであるPatch Queue Manager (PQM)
+は自動化ゲートキーパーの機能を提供します。
+
+
+ワークフローを実施する
+-----------------------
+
+上記のそれぞれのワークフローを実施する方法を詳しく知りたいのであれば、\
+このマニュアルの3章から6章までを参照してください。最初に、2章で、\
+インストール方法、一般的な使い方の手引きと設定方法に関するティップス\
+が説明されています。
diff --git a/doc/ja/user-guide/branching_a_project.txt b/doc/ja/user-guide/branching_a_project.txt
new file mode 100644
index 0000000..d15e118
--- /dev/null
+++ b/doc/ja/user-guide/branching_a_project.txt
@@ -0,0 +1,118 @@
+プロジェクトをブランチする
+===========================
+
+ブランチのURL
+--------------
+
+誰かがあなたの作品のコピーを手に入れる前に、転送プロトコルを理解する必要があります。
+ブランチのトップレベルのディレクトリを、Windowsユーザーが慣れ親しんだ方法で、\
+ネットワーク上で共有することを決定するとします。
+LinuxとOS Xのユーザーは、大抵のSSHサーバーに組み込まれているセキュアなプロトコルである、\
+SFTPを通してアクセスする方が望ましいです。
+Bazaarは下記で一部が示されるたくさんのプロトコルのサポートに関して *とても* 柔軟です。
+
+ =========== ==========================================================================
+ スキーム 説明
+ =========== ==========================================================================
+ \file:// 標準ファイルシステムを利用してアクセスする (デフォルト)
+ \bzr+ssh:// SSH ごしのアクセス (リモートで最良の選択肢).
+ \sftp:// SFTPを利用してアクセスする (大抵のSSHサーバーはSFTPを提供する)
+ \bzr:// Bazaarのスマートサーバーを利用した高速のアクセス
+ \ftp:// パッシブFTPを利用してアクセスする
+ \http:// Webサーバーによって公開されたブランチへのアクセス
+ \https:// Webサーバーによって公開されたブランチへの、暗号化されたアクセス
+ =========== ==========================================================================
+
+上記で示されるように、ブランチは転送プロトコルを示すスキームを伴うURLを使用して識別されます。
+スキームが無ければ、通常のファイルの名前が想定されます。
+サポートされるプロトコルの完全なリストに関しては、
+``urlspec`` のオンライントピックもしくはBazaarのユーザーリファレンスの
+`URLの識別子 <../user-reference/index.html#url-identifiers>`_
+のセクションを参照してください。
+
+URL は通常サーバーのルートディレクトリから解決されます。
+なので、 ``ftp://example.com/repo/foo`` はそのホストの ``/repo/foo``
+ディレクトリを意味しています。(「通常」といっているのは、Apacheの
+ようないくつかのサーバーソフトウェアはURLを任意の場所にリマップ
+できるからです。この場合はサーバーの設定ファイルを確認して、
+どのURLがどのディレクトリを参照しているかを探さないといけないでしょう)
+
+サーバー上の自分のホームディレクトリからの相対パスを使うには、チルダを
+使います。たとえば ``bzr+ssh://example.com/~/public_html`` と書くと、
+ホームディレクトリの中の ``public_html`` ディレクトリにマップされます。
+
+.. note:: HTTP や HTTPS ごしのアクセスはデフォルトでは読み込み専用です。
+ 読み書き両方に対応するための設定については、
+ `HTTP スマートサーバーごしの push <http_smart_server.html#pushing-over-the-http-smart-server>`_
+ を参照してください。
+
+.. _a-reminder-about-shared-repositories:
+
+共用レポジトリに関するリマインダ
+---------------------------------
+
+ブランチのコピーを手に入れる前に、ファイルシステム上に設置する場所を少し考えて\
+みましょう。
+最大限のストレージの効率性のために、共用リポジトリとしてセットアップされた\
+ディレクトリの元でブランチを作ることを推奨します。
+(よく使われるレイアウトについては、 `作業スペースを構成する
+<organizing_your_workspace.html>`_ の中の `ブランチの機能
+<organizing_your_workspace.html#feature-branches>`_
+を参照してください)
+たとえば::
+
+ bzr init-repo my-repo
+ cd my-repo
+
+誰からでもブランチを入手して好きなようにする準備ができました。
+
+ブランチのコマンド
+-------------------
+
+既存のブランチに基づいたブランチを手に入れるためには、 ``branch``
+コマンドを使用してください。構文は次のとおりです::
+
+ bzr branch URL [directory]
+
+ディレクトリの名前が渡されない場合、URLの最後の部分に基づいてディレクトリが作成されます。
+ドライブ名 (M:/) とSFTPのURLを示すそれぞれの例は次のとおりです::
+
+ bzr branch M:/cool-trunk
+ bzr branch sftp://bill@mary-laptop/cool-repo/cool-trunk
+
+新しいブランチを使うために明示的にディレクトリの名前を渡す例は次のとおりです::
+
+ bzr branch /home/mary/cool-repo/cool-trunk cool
+
+時間とスペースへの考慮
+-----------------------
+
+転送されるブランチのサイズと コンピュータとソースのブランチの間のネットワーク帯域と
+レイテンシによっては、この初期の転送は少し時間がかかります。
+その後の更新は変更のみが転送されるので遙かに速くなります。
+
+Bazaarは最新のスナップショットではなくブランチの完全な履歴を転送することを覚えておいてください。
+結果として、 ``branch`` を完了させた後でネットワークから離脱しても、
+ブランチの履歴に対して ``log`` と ``diff`` を好きなだけ行うことができます。
+さらに、履歴がローカルで保存されているのでこれらのオペレーションは速いです。
+
+Bazaarはバージョンの履歴を保存するために求められるディスクスペースの総量を\
+最小限にするスマートな圧縮技術を使うことに注意してください。
+多くの場合、プロジェクトの完全な履歴は最新バージョンの作業コピーよりも少ない\
+ディスクスペースを占めます。
+
+後の章で説明するように、Bazaarはブランチの軽量チェックアウト、
+すなわち履歴のローカルなストレージなしの作業ツリーもサポートします。
+もちろん、接続しない使い方は利用できませんが、ローカルディスクスペースが\
+本当に厳しいのであればそれはあなたが決めることができるトレードオフです。
+現在、制限された履歴の振り返りのためのサポート - *履歴の水平線(history horizon)* -
+は開発段階にあります。
+
+ブランチの情報を閲覧する
+-------------------------
+
+配布元も含むブランチの情報を見たいのであれば、 ``info`` コマンドを使います::
+
+ bzr info cool
+
+ブランチが引数として渡されなければ、現在のブランチの情報が表示されます。
diff --git a/doc/ja/user-guide/browsing_history.txt b/doc/ja/user-guide/browsing_history.txt
new file mode 100644
index 0000000..d7bebe6
--- /dev/null
+++ b/doc/ja/user-guide/browsing_history.txt
@@ -0,0 +1,93 @@
+履歴を閲覧する
+================
+
+bzr log
+-------
+
+``bzr log`` コマンドは以前のリビジョンの一覧を表示します。
+
+``bzr diff`` と同じように, ``bzr log`` は ``-r`` の引数をサポートします::
+
+ % bzr log -r 1000.. # リビジョン1000とその後のすべて
+ % bzr log -r ..1000 # r1000とそれまでのすべて
+ % bzr log -r 1000..1100 # 1000から1100までの変更
+ % bzr log -r 1000 # リビジョン1000のみの変更
+
+マージされたリビジョンを見る
+------------------------------
+
+Bazaarのような分散型のVCSは集中型のVCSツールよりもマージが非常に簡単なので、
+ブランチの履歴は、メインラインから分離してその後メインラインにマージされる\
+ようなラインを含むことがあります。
+技術的には、無数のリビジョンノード間の関係は無閉路有向グラフ(Directed Acyclic Graph: DAG)として知られます。
+
+多くの場合、まずはメインラインを見てそのあとに別のラインを見たいものです。
+そのため、log のデフォルトの動作はメインラインを表示して、マージされた\
+リビジョンがあるある場所を指示します。::
+
+ bzr log -n0 -rX
+
+全てのリビジョンと全てのマージされたリビジョンを見る場合は::
+
+ bzr log -n0
+
+-n オプションは表示するレベルを意味し、0の場合は全てを意味することに注意してください。
+もしそれがゴミゴミしているなら、値を変更して調整することが容易にできます。
+たとえば、もしあなたのプロジェクトがトップレベルのgatekeeperがチームレベルのgatekeeperからマージするように構成されている場合、\
+``bzr log`` はトップレベルgatekeeperの履歴だけを表示し、 ``bzr log -n2``
+はチームのgatekeeperの履歴を表示します。
+しかし、ほとんどの場合においては ``-n0`` で十分でしょう。
+
+
+出力をチューニングする
+-----------------------
+
+``log`` コマンドは出力を調整するために便利ないくつかのオプションを持ちます。次のものが含まれます:
+
+ * ``--forward`` はログを年代順で表します。
+ すなわち最新のリビジョンが最後に表示されます。
+
+ * ``--limit`` オプションは表示されるリビジョンの最大数を制御します。
+
+出力の調整方法の詳しい情報に関してはユーザーリファレンスのlogコマンドのオンラインヘルプを参照してください。
+
+ファイルの履歴を閲覧する
+-------------------------
+
+特定のファイルのみに適用されるように履歴をフィルタリングすることが便利であることがよくあります。
+これを行うためには、ファイルの名前を ``log`` コマンドに提供します::
+
+ bzr log foo.py
+
+古いバージョンのファイルを閲覧する
+-----------------------------------
+
+指定されたバージョンでファイルの内容を取得するには、次のように ``cat`` コマンドを使います::
+
+ bzr cat -r X file
+
+``X`` はリビジョンの識別子で ``file`` はファイルの名前です。
+これは出力を標準出力ストリームに送信しますので、次のように\
+閲覧ツール( ``less`` や ``more`` など)に出力をパイプで渡すか\
+リダイレクトするといいでしょう::
+
+ bzr cat -r -2 foo.py | less
+ bzr cat -r 1 foo.py > /tmp/foo-1st-version.py
+
+グラフィカルな履歴ビューワ
+----------------------------
+
+履歴のブラウジングはGUIツールが人生を本当に楽にしてくれる領域です。
+QBzrとbzr-gtkを含めてこの機能を提供するBazaarのプラグインがたくさんあります。
+これらがまだインストールされていなければ `プラグインを利用する <plugins.html>`_ で詳細なインストール方法をご覧ください。
+
+QBzrからグラフィカルビューワを使うには::
+
+ bzr qlog
+
+bzr-gtkからグラフィカルビューワを使うためには::
+
+ bzr viz
+
+``viz`` は実際には ``visualize`` の組み込みのエイリアスなので望むのであれば長い方のコマンド名を使います。
+
diff --git a/doc/ja/user-guide/bug_trackers.txt b/doc/ja/user-guide/bug_trackers.txt
new file mode 100644
index 0000000..a9e6e14
--- /dev/null
+++ b/doc/ja/user-guide/bug_trackers.txt
@@ -0,0 +1,49 @@
+バグトラッカー
+===============
+
+Bazaarにはコミットをプロジェクトのバグトラッカーのバグに関連づけできる機能があります。
+コミットとバグの間のハイパーリンクを生成する、もしくはコミットを含むブランチで閉じた\
+バグを自動的にマークするために、他のツール (もしくはフック) はこの情報を使うことができます。
+
+コミットとバグを関連付ける
+---------------------------
+
+コミットを行うとき、 ``commit`` の ``--fixes`` オプションを利用することでバグと関連付けることができます。例です::
+
+ $ bzr commit --fixes lp:12345 -m "Properly close the connection"
+
+このコマンドの実行によってコミットとLaunchpdのバグ12345とリンクするBazaarのメタデータが記録されます。
+異なるバグトラッカーを使う場合、( ``lp`` の代わりに) 独自のトラッカーコードを渡して代わりに使うことができます。
+Bugzilla、Trac、Roundupとその他のバグ/問題トラッカーに対してこれを設定する方法の詳細に関しては、
+Bazaarユーザーリファレンスの `バグトラッカーの設定`_ を参照してください。
+
+.. _バグトラッカーの設定: ../user-reference/index.html#bug-tracker-settings
+
+メタデータの記録 vs バグトラッカーの更新
+------------------------------------------
+
+コミット時に修正されたバグに関するメタデータの記録は完全なバグトラッカーの統合機能の中で唯一必要なものです。
+Bazaarは分散型VCSなので、ユーザーがオフラインでコミットしているためバグトラッカー自身へのアクセスが不可能な場合があります。
+代わりに、プロジェクトのワークフローに適切な中心位置に変更をpushするとき、\
+バグトラッカーを更新するためにフックをインストールすることが推奨されます。
+
+注: この2番目の処理段階はLaunchpadの外部もしくはホストされているブランチがスキャンされるときに
+Launchpadによって提供される統合機能の一部です。
+
+訂正をする
+-----------
+
+リビジョンとバグを関連付けるこの方法にはいくつかの制限があります。
+最初のものは関連づけはコミット時のみにしかできないことです。
+このことは、コミットするもしくは修正した後でバグが報告することを忘れた場合、
+一般的に後から差し戻してリンクを追加できないことを意味します。
+
+これに関連したことは関連づけは不変であるという事実です。
+バグがあるコミットによって修正されたものとしてマークされたが、リビジョンがバグを十分に解決しない、
+もしくは後で回帰がある場合、差し戻してリンクを削除できません。
+
+もちろん、正しいオプションで行うために最新コミットをアンドゥする ``bzr uncommit`` が常に使われます。
+これは正しくないコミットメッセージを訂正するためによく行われ、(たとえば ``--fixes`` を通した)最新コミットに
+記録されたメタデータを訂正するために等しく当てはまります。
+
+注: 正しくないリビジョンが公開される前に ``uncommit`` を行うのがベストです。
diff --git a/doc/ja/user-guide/bzrtools_plugin.txt b/doc/ja/user-guide/bzrtools_plugin.txt
new file mode 100644
index 0000000..21b470a
--- /dev/null
+++ b/doc/ja/user-guide/bzrtools_plugin.txt
@@ -0,0 +1,32 @@
+BzrTools
+========
+
+概要
+-----
+
+BzrToolsは便利なBazaar強化機能のコレクションです。
+インストールの手引きに関しては、BzrToolsのホームページを参照してください:
+http://wiki.bazaar.canonical.com/BzrTools.
+よく使われるコマンドのサンプルは下記のとおりです。
+
+
+shell
+-----
+
+``bzr shell`` はBazaarのコマンドを理解する以上のことを行うコマンドインタープリタを起動します。
+これはいくつかの利点を持ちます:
+
+ * すべてのコマンドの冒頭で ``bzr`` を入力する必要が無くなります。
+
+ * インテリジェントな自動入力補完が提供されます。
+
+ * Bazaarのライブラリを毎回ロードする必要がないのでコマンドは少し速く動作します。
+
+
+cdiff
+-----
+
+``bzr cdiff`` は GNU/Linux、UNIXとOS Xで ``bzr diff`` の出力の色つきバージョンを提供します。
+次のようによく使われます::
+
+ bzr cdiff | less -R
diff --git a/doc/ja/user-guide/central_intro.txt b/doc/ja/user-guide/central_intro.txt
new file mode 100644
index 0000000..0bbe86a
--- /dev/null
+++ b/doc/ja/user-guide/central_intro.txt
@@ -0,0 +1,32 @@
+集中型の開発
+=============
+
+動機
+-----
+
+並行して作業をして時折マージするよりも、ロックステップ、\
+すなわち複数の人が継続して変更を中心位置にコミットして\
+すべてのコミットの前に彼らの作業内容を最新の内容にマージすること、\
+で一度に作業をすることは有用であることがあります。
+
+このワークフローはSubversionとCVSのような集中型のVCSツールのユーザーには\
+とても慣れ親しまれています。
+単独の開発者が複数のマシンに取り組む場合にも応用できます。たとえば、\
+通常はデスクトップで作業をするが旅行の間はラップトップ、\
+もしくは(インターネットに接続した)ホームコンピュータで\
+勤務時間外に事務作業を完了させるといった具合です。
+
+あなたのチームがすでに集中型の開発でうまくいっているのであれば、それは\
+素晴らしいことです。
+多くのチームはこの方法でBazaarを使い始め、後で代替のワークフローを実験します。
+
+集中型のワークフロー
+---------------------
+
+下記のダイアグラムは *集中型のワークフロー* の概要を提供します。
+
+.. image:: images/workflows_centralized.png
+
+あなたのチームがより分散型のワークフローを利用することを計画しているとしても、
+この章でカバーされる多くのタスクは、とりわけブランチを公開する方法に関して\
+あなたにとって有用です。
diff --git a/doc/ja/user-guide/configuring_bazaar.txt b/doc/ja/user-guide/configuring_bazaar.txt
new file mode 100644
index 0000000..f072564
--- /dev/null
+++ b/doc/ja/user-guide/configuring_bazaar.txt
@@ -0,0 +1,187 @@
+Bazaarを設定する
+==================
+
+Bazaarにあなたの名前を教える
+-----------------------------
+
+バージョン管理システムの機能の1つは誰が何を変更したのかを追跡することです。
+分散型のシステムでは、その機能を実現するためにグローバルにユニークな\
+それぞれの著者のための識別子が必要です。
+大抵の人はそれらの1つを持っています: Eメールアドレスです。
+Bazaarはあなたのユーザー名とホスト名を探し出してEメールアドレスを自動的に\
+生成します。
+Bazaarが行う推測を望まないのであれば、あなたが望む識別子を設定するために
+``whoami`` コマンドを使います::
+
+ % bzr whoami "Your Name <email@example.com>"
+
+``whoami`` は引数なしで使われると、現在の値が表示されます。
+
+
+.. Using a network proxy
+
+ネットワークプロクシを使う
+---------------------------
+
+ネットワークが外部への接続に HTTP プロクシを必要とする場合、
+``http_proxy`` という環境変数を設定しなければなりません。
+https 接続にもプロクシが必要なら、 ``https_proxy`` も設定しなければなりません。
+プロクシが必要なのにこれらの環境変数が設定されていない場合、
+Launchpad やその他の外部のサーバーへの接続ができなかったりタイムアウトしたりします。
+
+Unix では、たいていこれらの設定は ``/etc/environment`` か
+``~/.bash_profile`` に書いて、 Windows ではたいていユーザープロファイルで
+設定します。
+
+::
+
+ http_proxy=http://proxy.example.com:3128/
+ https_proxy=http://proxy.example.com:3128/
+
+The ``no_proxy`` variable can be set to a comma-separated list of hosts
+which shouldn't be reached by the proxy. (See
+<http://docs.python.org/library/urllib.html> for more details.)
+
+``no_proxy`` という環境変数に、プロクシを利用しないで到達するホスト名の
+リストをカンマ区切りで設定できます。
+(詳細は <http://docs.python.org/library/urllib.html> を参照してください)
+
+
+.. Various ways to configure
+
+いろいろな設定方法
+-------------------------
+
+上の例で示したように Bazaar を設定する方法はたくさんありますが、
+全てに共通している属性があります。オプションは全て以下のように
+なっています。
+
+- 名前は有効な Python の識別子です。
+
+- a value which is a string. In some cases, Bazaar will be able
+ to recognize special values like 'True', 'False' to infer a
+ boolean type, but basically, as a user, you will always specify
+ a value as a string.
+
+- 値は文字列です。いくつかの場面では、真偽値を得るために Bazaar は `True`,
+ `False` のような特別な値を認識しますが、基本的にはユーザーは値として
+ ただの文字列を渡します。
+
+オプションはコンテキストによってグループ化されており、オプション名は
+そのコンテキスト内ではユニークに識別することができます。
+必要な場合、オプションは設定ファイルに保存され永続化されます。
+
+
+設定ファイル
+-------------
+
+設定ファイルは Unix の場合 ``$HOME/.bazaar`` に、 Windows の場合
+``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` にあります。
+この場所には3つの主要な設定ファイルがあります:
+
+* ``bazaar.conf`` はデフォルトの設定オプションを記述します。
+
+* ``locations.conf`` は特定のブランチの位置を記述しますd
+
+* ``authentication.conf`` はリモートサーバーのためのクレデンシャルな情報を記述します
+
+それぞれのブランチも特定の値をそのブランチに設定する設定ファイルを含みます。
+このファイルはブランチの中の ``.bzr/branch/branch.conf`` で見つかります。
+このファイルは **ブランチのすべてのユーザー** に見えます。
+あなたに固有の設定を持つブランチのための値の1つを上書きしたいのであれば、
+``locations.conf`` でそれを行うことができます。
+
+``whoami`` コマンドを使用してEメールアドレスを設定した後の ``bazaar.conf`` の内容のサンプルは次のとおりです::
+
+ [DEFAULT]
+ email = Your Name <email@example.com>
+
+サポートされる構文と構成設定の詳細については、
+Bazaar のユーザーリファレンスの
+`構成設定 <../user-reference/index.html#configuration-settings>`_
+の項目を参照してください。
+
+
+.. Looking at the active configuration
+
+アクティブな設定を確認する
+-----------------------------------
+
+現在定義されている全てのオプションを確認するには、次のコマンドを実行します。 ::
+
+ bzr config
+
+``bzr`` は設定オプションをどこから取得するかを決定するためのいくつかのルールを
+持っています。
+
+現在のポリシーでは、以下の順序でマッチする定義を設定ファイルから探します。
+
+ * 最初に ``location.conf`` の中の、セクション名が場所(作業ツリー、ブランチ、
+ リモートブランチ)にマッチするセクションが探されます。
+
+ * 次に現在の ``branch.conf`` が探されます。
+
+ * 次に ``bazaar.conf`` が探されます。
+
+ * 最後に、いくつかのオプションはコード中で定義されたデフォルト値が設定され、
+ この設定は ``bzr config`` には表示されません。
+ (`構成設定 <../user-reference/index.html#configuration-settings>`_
+ を参照してください。)
+
+この動作は、 ``bzr config`` を引数なしで実行すると理解しやすいはずです。
+このコマンドを実行すると次のような表示をします。 ::
+
+ locations:
+ post_commit_to = commits@example.com
+ news_merge_files = NEWS
+ branch:
+ parent_location = bzr+ssh://bazaar.launchpad.net/+branch/bzr/
+ nickname = config-modify
+ push_location = bzr+ssh://bazaar.launchpad.net/~vila/bzr/config-modify/
+ bazaar:
+ debug_flags = hpss,
+
+各オプション定義のグループの前に表示されているスコープが、
+そのオプションを定義している構成設定ファイルを表しています。
+
+
+.. _modifying-the-active-configuration:
+
+有効な設定を変更する
+----------------------------------
+
+オプションに値を設定するには::
+
+ bzr config opt=value
+
+オプションの利用を止めるには::
+
+ bzr config --remove opt
+
+
+ルールベースのプリファレンス
+-----------------------------
+
+いくつかのコマンドとプラグインは特定のパターンにマッチするファイルのカスタムの処理機能を提供します。
+ユーザーごとにルールベースのプリファレンスが ``BZR_HOME/rules`` で定義されます。
+
+ルールが検索される検索方法と関連ファイルの詳細な構文に関する詳細については、
+Bazaarのユーザープリファレンスの `ルール <../user-reference/index.html#rules>`_
+の項目を参照してください。
+
+
+.. _escaping-command-lines:
+
+コマンドラインのエスケープ
+--------------------------------
+
+設定ファイルの中にプログラム名やコマンドラインを記述する場合、特殊な文字や
+スペースをその中に含めるためにクォートすることができます。
+同じルールが全てのプラットフォームで有効です。
+
+そのルールとは、ダブルクォートで囲まれた文字列はスペースが含まれていたとしても
+1つの「語」として認識され、クォート文字をクォートの中に含めるためにバックスラッシュ
+(訳注: 日本語環境では多くの場合バックスラッシュではなく円記号(ASCII文字の0x5c)です)
+を使います。例えば::
+
+ BZR_EDITOR="C:\Program Files\My Editor\myeditor.exe"
diff --git a/doc/ja/user-guide/controlling_registration.txt b/doc/ja/user-guide/controlling_registration.txt
new file mode 100644
index 0000000..13fc9b3
--- /dev/null
+++ b/doc/ja/user-guide/controlling_registration.txt
@@ -0,0 +1,91 @@
+ファイルの登録を制御する
+=========================
+
+Bazaarは何を追跡するのか?
+--------------------------
+
+前に説明したように、 ``bzr add`` は現在のディレクトリの元でBazaarがバージョン管理すべきだと考える
+すべてのものを見つけ登録します。登録するものは次のようなものになります:
+
+ * ファイル
+ * ディレクトリ
+ * シンボリックリンク
+
+Bazaarは興味を持つファイルと興味を持たないファイルに関してデフォルトのルールを持ちます。
+後で説明される `ファイルを無視する`_ のようにこれらのルールを調整できます。
+
+他の多くのVCSツールとは異なり、Bazaarはディレクトリを第一級の項目として扱います。
+結果として、空のディレクトリは正しくサポートされます -
+ディレクトリが追跡されプロジェクトのエクスポートに含まれることを保証するために
+ディレクトリ内部にダミーファイルを作る必要はありません。
+
+シンボリックリンクに関しては、シンボリックリンクの値は追跡され、
+シンボリックリンクが指し示すものの内容は追跡されません。
+
+注: プロジェクトの中のプロジェクトを追跡するサポート機能 ("入れ子ツリー") は現在開発中です。
+この機能の開発を手伝うもしくはテストすることにご興味がありましたらBazaarの開発者に連絡して下さるようお願いします。
+
+登録を選ぶ
+-----------
+
+いくつかの事例において、登録したいものをBazaarに発見を任せるよりも明示的に指名したいことがあります。
+これを行うためには、パスを引数として ``add`` コマンドに提供します::
+
+ bzr add fileX dirY/
+
+ディレクトリを追加すると暗黙的にそのディレクトリの中の関心のあるすべてのものが追加されます。
+
+ファイルを無視する
+-------------------
+
+エディタのバックアップ、オブジェクト、バイトコードのファイル、ビルドされたプログラムなど、
+多くのソースツリーはバージョン管理する必要のないファイルを含みます。
+単純にこれらを追加しないでおくと、これらは常に未知のファイルとして現れます。
+ツリーのトップでこれらを ``.bzrignore`` と呼ばれるファイルに追加することでBazaarにこれらのファイルを無視するように指示することもできます。
+
+このファイルは一行ごとにファイルのワイルドカード(もしくは "globs")の一覧を含みます。典型的な内容は次のとおりです::
+
+ *.o
+ *~
+ *.tmp
+ *.py[co]
+
+globがスラッシュを含む場合、ツリーのトップからのパス全体がマッチします;
+さもなければファイルの名前だけにマッチします。以前の例では
+すべてのサブディレクトリ内の ``.`` の拡張子を持つファイルが無視されますが、
+次の例ではトップレベルでは ``config.h`` だけと ``doc/`` の中のHTMLが無視されます::
+
+ ./config.h
+ doc/*.html
+
+どのファイルが無視され何のパターンにマッチするのかについての一覧表を得るためには、 ``bzr ignored`` を使います::
+
+ % bzr ignored
+ config.h ./config.h
+ configure.in~ *~
+
+無視するパターンがバージョン管理されていないファイルのみにマッチし、それらが"unknown"もしくは"ignored"として扱われるのかを制御します。
+ファイルが明示的に追加されると、無視するパターンにマッチするかに関わらずバージョン管理されたままです。
+
+``.bzrignore`` ファイルは通常はバージョン管理されるので、ブランチの新しいコピーは同じパターンを見ます::
+
+ % bzr add .bzrignore
+ % bzr commit -m "Add ignore patterns"
+
+``bzr ignore PATTERN`` コマンドはPATTERNを ``.bzrignore`` ファイルに手軽に追加するために使われます
+(必要でBazaarによって追跡するために登録する場合、作られます)。
+``.bzrignore`` ファイルを直接編集することでパターンの除去と修正が行われます。
+
+グローバルで無視する
+---------------------
+
+プロジェクト固有のものではないが、ユーザー固有の無視されるファイルがいくつかあります。
+編集者用の一時ファイルもしくは個人の一時ファイルのようなものです。
+これらを無視するようにすべてのプロジェクトに追加するよりも、
+bzrは ``~/.bazaar/ignore`` の中でグローバルで無視するファイルをサポートします [#]_ 。
+これはプロジェクト単位で無視するファイルと同じ構文を持ちます。
+
+.. [#] Windowsにおいて、ユーザーの設定ファイルはアプリケーションデータディレクトリで見つかります。
+ ``~/.bazaar/branch.conf`` の代わりに、設定ファイルは次のように見つかります:
+ ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``
+ 同じことが ``locations.conf`` 、 ``ignore`` 、と ``plugins`` ディレクトリにも当てはまります。
diff --git a/doc/ja/user-guide/core_concepts.txt b/doc/ja/user-guide/core_concepts.txt
new file mode 100644
index 0000000..bfa91a5
--- /dev/null
+++ b/doc/ja/user-guide/core_concepts.txt
@@ -0,0 +1,121 @@
+コアの概念
+===========
+
+単純なユーザーモデル
+---------------------
+
+Bazaarを使うために理解する必要のある概念は4つあります:
+
+* **リビジョン(Revision)** - 取り組むファイルのスナップショット
+
+* **作業ツリー(Working tree)** - バージョン管理されたファイルとサブディレクトリを含むディレクトリ
+
+* **ブランチ(Branch)** - ファイルの履歴を記述する、順序づけされたリビジョンの集合
+
+* **リポジトリ(Repository)** - リビジョンの貯蔵場所
+
+それぞれを詳しく見てみましょう。
+
+リビジョン
+-----------
+
+リビジョンはファイルとディレクトリの内容と形を含むそれらのツリーの状態の **スナップショット** です。
+リビジョンはそれ自身に関連づけされたメタデータをいくつか含みます。メタデータには次のようなものが含まれます:
+
+* コミットした人
+* コミットした時間
+* コミットメッセージ
+* そのリビジョンの元になった親のリビジョン
+
+リビジョンは不変で、グローバルかつユニークに **リビジョンid (revision-id)** で識別できます。
+リビジョンidの例は次のとおりです::
+
+ pqm@pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz
+
+リビジョンidはコミットする、もしくは他のシステムからインポートする時点で生成されます。
+リビジョンidは内部で利用するときや外部ツールとの統合に必要ですが、
+ブランチ固有の **リビジョン番号** (*revision numbers*)の方が人間に好まれるインタフェースに\
+なります。
+
+リビジョン番号は 1 や 42 や 2977.1.59 のようにドットで区切られた10進法の識別子で\
+ブランチに対するリビジョン番号のグラフを通してパスを追跡します。
+リビジョン番号は一般的にリビジョンidよりも短く、単独のブランチの範囲では
+それらの関係を理解するためにそれぞれを比較できます。
+たとえば、リビジョン10はリビジョン9の直後のメインライン(下記を参照)のリビジョンです。
+リビジョン番号はコマンドが実行されているときに生成されます。
+これらはブランチ内でどのリビジョンがチップ(すなわち最新のリビジョン)であるかに依存するからです。
+
+Bazaarで指定できるリビジョンとリビジョンの範囲のいくつかの方法に関しては、付録の
+`リビジョンを指定する <specifying_revisions.html>`_ を参照してください。
+リビジョンの番号付けの詳細に関しては `リビジョン番号を理解する <zen.html#understanding-revision-numbers>`_
+を参照してください。
+
+.. *TODO: add diagram*
+
+作業ツリー
+------------
+
+作業ツリー(working tree)は ユーザーが編集できるファイルを保持する
+*バージョン管理されたディレクトリ* です。
+作業ツリーは *ブランチ* に関連付けされます。
+
+多くのコマンドは作業ツリーをそれぞれの文脈で使います。
+たとえば、 ``commit`` コマンドは作業ツリーの中のファイルの\
+現在の内容を利用して新しいリビジョン番号を作ります。
+
+.. *TODO: add diagram*
+
+ブランチ
+---------
+
+最もシンプルな場合、ブランチは *順序づけされた一連のリビジョン* です。
+最終リビジョンは *チップ(tip)* として知られます。
+
+ブランチは分かれたりその後再結合(*marged* back)されたりして、\
+グラフの形をとります。
+技術的にいえば、グラフは(親と子のリビジョンの間)の有行な関係を表し、\
+ループが存在しないので、 *directed acyclic graph* (DAG) として\
+言及されるかもしれません。
+
+この名前にギョッとするかもしれませんが、ご心配なく。
+覚えておくべき重要なことは次のとおりです:
+
+* DAGの範囲内での開発の主要なラインは *メインライン(mineline)*,
+ *トランク(trunk)*, もしくは単に *左側(left hand side: LHS)* と呼ばれます。
+
+* ブランチはメインラインではない開発ラインを持つことがあります。
+ そのとき、別のラインはある時点で始まり別の時点で終わります。
+
+.. *TODO: add diagram*
+
+レポジトリ
+-----------
+
+レポジトリはシンプルにいえば *リビジョンの保管場所* です。
+最もシンプルな事例では、それぞれのブランチが独自のレポジトリを持ちます。\
+別の事例では、ディスクの使用量を最適化するためにブランチに対してレポジトリを\
+共用しています。
+
+.. *TODO: add diagram*
+
+概念をまとめる
+---------------
+
+上記の概念を把握したら、Bazaarのさまざまな使い方が理解しやすくなります。
+Bazaarの最もシンプルな使い方は *スタンドアロンツリー(standalone tree)* で、\
+これは1つの位置に作業ツリー、ブランチとレポジトリのすべてが含まれます。
+他のよくあるシナリオには次のようなものがあります:
+
+* `共用リポジトリ(shared branch) <branching_a_project.html#a-reminder-about-shared-repositories>`_
+ - 作業ツリーとブランチは同じディレクトリにありますが、リポジトリは高い階層の\
+ ディレクトリに存在します。
+
+* `スタックブランチ(stacked branch) <stacked.html>`_
+ - 親のリポジトリと共通なリビジョンは親のリポジトリのものを利用することで、
+ ブランチはユニークなリビジョンだけを保存します。
+
+* `軽量チェックアウト(lightweight checkout) <using_checkouts.html#getting-a-lightweight-checkout>`_
+ - 作業ツリーとは別の場所にブランチが保存されます。
+
+Bazaarを使う最良の方法は、あなたのニーズ次第です。
+次に共通のワークフローを見てみましょう。
diff --git a/doc/ja/user-guide/distributed_intro.txt b/doc/ja/user-guide/distributed_intro.txt
new file mode 100644
index 0000000..3c7f6c6
--- /dev/null
+++ b/doc/ja/user-guide/distributed_intro.txt
@@ -0,0 +1,24 @@
+分散型の開発
+=============
+
+動機
+----
+
+分散型のVCSツールは共同作業の新しい方法を提供します。
+これは私達が生きる現代の世界をより反映したものでより高い品質の\
+成果を可能にします。
+
+分散型の共用のメインラインのワークフロー
+-----------------------------------------
+
+このワークフローにおいて、それぞれの開発者は1つもしくは複数の\
+独自のブランチに加えて、メインブランチのチェックアウトを持ちます。
+開発者は個人のブランチに取り組み、準備ができたら、それをメインラインに\
+マージします。
+
+.. image:: images/workflows_shared.png
+
+他の分散型のワークフローはこの章の後ろの方で検討します。
+
+..
+ vim: tw=74 ft=rst
diff --git a/doc/ja/user-guide/entering_commands.txt b/doc/ja/user-guide/entering_commands.txt
new file mode 100644
index 0000000..7f089f6
--- /dev/null
+++ b/doc/ja/user-guide/entering_commands.txt
@@ -0,0 +1,36 @@
+コマンドを入力する
+===================
+
+ユーザーインターフェイス
+-------------------------
+
+Bazaarに対して利用可能な数多くのユーザーインターフェイスが存在します。
+コアパッケージは **bzr** と呼ばれるコマンドラインツールを提供し
+グラフィカルユーザーインターフェイス(GUI)はプラグインとして利用できます。
+
+bzrを使う
+---------
+
+構文は次のとおりです::
+
+ bzr [グローバルオプション] command [オプションと引数]
+
+グローバルオプションはBazaarの動作方法に影響を与え ``command`` の前後に現れます。コマンド特有のオプションはコマンドの後で指定しなければなりませんが、コマンド固有の引数の前後と間で指定することができます。
+
+共通のオプション
+-----------------
+
+下記で示されるいくつかのオプションはすべてのコマンドに対して有効です。
+
+ ========== ========= =================
+ 短い形式 長い形式 説明
+ ========== ========= =================
+ -h --help get help
+ -v --verbose be more verbose
+ -q --quiet be more quiet
+ ========== ========= =================
+
+Quietモードはエラーと警告のみを表示します。これはスクリプトで使う際に便利です。
+
+注: 大抵のコマンドは1つのレベルの冗長性だけをサポートします。今後これは変更されるかもしれません。
+高度な冗長性を求めるためには、-vオプションを複数回指定するだけです。
diff --git a/doc/ja/user-guide/filtered_views.txt b/doc/ja/user-guide/filtered_views.txt
new file mode 100644
index 0000000..8d3210c
--- /dev/null
+++ b/doc/ja/user-guide/filtered_views.txt
@@ -0,0 +1,162 @@
+Filtered views
+==============
+
+Filtered view の紹介
+--------------------------
+
+Viewはtreeに対するマスクを提供し、ユーザーはtreeの一部分に集中できる\
+ようになります。
+このマスキングが役に立ついくつかの場面があります。たとえば、大きな\
+プロジェクトの技術ライターやテスターはプロジェクトのうち一部のディレクトリ\
+やファイルだけを扱います。
+
+開発者は大規模な変更をviewを使っていくつかのコミットに分解したいと思う\
+かもしれません。 ``shelve`` ``unshelve`` がいくつかの変更を後のコミットまで\
+とっておくのに対して、viewは次のコミットに(何を含めないかではなく)何を\
+含めるかを指定します。
+
+viewを作った後は、ファイルリストをサポートするコマンド - status,
+diff, commit, etc - に暗黙的に毎回そのファイルリストが渡されます。
+それらのコマンドに明示的にファイルリストを渡すことも可能ですが、\
+指名するファイルは現在のviewの中にないといけません。
+対照的に、ツリーを対象とするコマンド - pull, merge, update, etc -
+はviewが作られた後もツリー全体に対して操作しますが、現在のviewに\
+関係するもののみを報告します。
+どちらのケースでも、Bazaarはユーザーに毎回viewが使われていることを\
+報告するので、操作や出力がマスクされていることが判ります。
+
+ノート: filtered view は 2a フォーマット(Bazaar 2.0 以降でデフォルトの
+フォーマット)でのみ有効です。
+
+
+view を作る
+---------------
+
+次のように, ``view`` コマンドにファイルやディレクトリを指定することで\
+viewを作ります::
+
+ bzr view file1 file2 dir1 ...
+
+出力は::
+
+ Using 'my' view: file1, file2, dir1
+
+
+現在のviewをリストする
+------------------------
+
+現在のviewを見るには、 ``view`` コマンドに引数をつけないで実行します::
+
+ bzr view
+
+もしviewが無ければ、 ``No current view.`` というメッセージが出力されるでしょう。
+そうでなければ、現在のviewの名前と内容が次のように表示されます::
+
+ 'my' view is: a, b, c
+
+
+viewを切り替える
+-----------------------
+
+ほとんどの場合、viewは「変更を選択するために作られて、\
+変更がコミットされると削除される」という具合に短い期間で使われます。
+それ以外の場合では、viewに名前をつけてそれを切り替えたい場合がある\
+かもしれません。
+
+名前つきviewを宣言してそれに切り替えるには::
+
+ bzr view --name view-name file1 dir1 ...
+
+たとえば::
+
+ bzr view --name doc NEWS doc/
+ Using doc view: NEWS, doc/
+
+名前つきviewを見るには::
+
+ bzr view --name view-name
+
+名前つきviewに切り替えるには::
+
+ bzr view --switch view-name
+
+全ての名前つきviewの一覧を得るには::
+
+ bzr view --all
+
+
+一時的にviewを無効にする
+----------------------------
+
+現在のviewを削除せずに無効にしたい場合、 ``off`` という名前の仮想viewに\
+切り替えることができます。これは、ツリー全体を一つか二つのコマンドで操作する\
+必要があり(例: merge)、しかしその後に元のviewに戻りたい場合に便利です。
+
+現在のviewを削除せずに無効にするには::
+
+ bzr view --switch off
+
+ツリー全体に対する操作が終わったら、元のviewの名前を指定して戻ることが\
+できます。たとえば、デフォルトの名前が使われて他のであれば::
+
+ bzr view --switch my
+
+
+viewを削除する
+--------------
+
+現在のviewを削除するには::
+
+ bzr view --delete
+
+名前つきviewを削除するには::
+
+ bzr view --name view-name --delete
+
+全てのviewを削除するには::
+
+ bzr view --delete --all
+
+
+注意点
+---------------------
+
+view を定義しても作業ツリー内のほかのファイルを削除するわけでは\
+ありません。単に作業ツリーに対する "レンズ" を提供するだけです。
+
+view は作業ツリーのメタデータとして保存されます。pull, push, update
+といったブランチコマンドを使っても他の作業ツリーに伝播しません。
+
+view はファイルパスの形で定義されます。もしview内のファイルをview外に
+移動したのであれば、view はそのファイルを追跡しません。
+たとえば、viewが ``doc/`` と定義されていて ``doc/NEWS`` を ``NEWS``
+に移動しても view は ``doc/`` に定義されたままで、 ``doc/`` と ``NEWS``
+のように変更されたりはしません。同じように、view内のファイルを削除しても\
+viewからはそのファイルパスは削除されません。
+
+
+現在のviewを利用するコマンドは:
+
+* status
+* diff
+* commit
+* add
+* remove
+* revert
+* mv
+* ls
+
+ツリー全体に対する操作だけれども現在のviewの中だけを報告するコマンドは:
+
+* pull
+* update
+* merge.
+
+現在のところ、多くのコマンドがviewを無視します。ニーズがある\
+コマンドから徐々に上の対応リストに追加されていくでしょう。
+いくつかのコマンドは全体図を見るのがより適しているために、\
+viewを無視したままになるでしょう。このタイプのコマンドには\
+次のものがあります:
+
+* log
+* info
diff --git a/doc/ja/user-guide/getting_help.txt b/doc/ja/user-guide/getting_help.txt
new file mode 100644
index 0000000..b45ec03
--- /dev/null
+++ b/doc/ja/user-guide/getting_help.txt
@@ -0,0 +1,22 @@
+helpを表示する
+==============
+
+Bazaar は組み込みのオンラインヘルプシステムを搭載していて、
+次のコマンドでアクセスできます。 ::
+
+ bzr help
+
+help コマンドで、コマンドやコマンド以外のトピックに着いて調べることができます。
+それぞれのヘルプの一覧を見るには次のようにします。 ::
+
+ bzr help commands
+ bzr help topics
+
+特定のコマンドのヘルプを見るには、次の2つの形式を使うことができます。 ::
+
+ bzr help status
+ bzr status --help
+
+ヘルプを検索するもしくは大きなドキュメントとして読みたい場合、
+情報はBazaarのユーザーリファレンスでも手に入ります。
+
diff --git a/doc/ja/user-guide/hooks.txt b/doc/ja/user-guide/hooks.txt
new file mode 100644
index 0000000..2b2e6ad
--- /dev/null
+++ b/doc/ja/user-guide/hooks.txt
@@ -0,0 +1,125 @@
+フックを利用する
+================
+
+フックとは?
+------------
+
+Bazaarのふるまいをカスタマイズする1つの方法は *フック(hook)* です。
+フックによって特定のBazaarの特定のオペレーションの前後でアクションを実行できます。
+オペレーションは ``commit``, ``push``, ``pull`` と ``uncommit`` を含みます。
+フックとパラメータの完全なリストに関しては、ユーザーリファレンスの
+`フック <../user-reference/index.html#hooks>`_ を参照してください。
+
+大抵のフックはクライアントで実行されますが、サーバーで実行されるものもわずかに
+あります。
+(サーバーサイドのオペレーションの特殊なケースを扱うものは
+`push-and-update plugin`_ も参照。)
+
+.. _push-and-update plugin: http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html
+
+
+フックを使用する
+-----------------
+
+フックを使用するには、 `プラグインを書きます`_ 。
+新しいコマンドを作成する代わりに、このプラグインはフックを定義してインストールします。例です::
+
+ from bzrlib import branch
+
+
+ def post_push_hook(push_result):
+ print "The new revno is %d" % push_result.new_revno
+
+
+ branch.Branch.hooks.install_named_hook('post_push', post_push_hook,
+ 'My post_push hook')
+
+.. _プラグインを書きます: http://doc.bazaar.canonical.com/plugins/en/plugin-development.html
+
+この例を使用するには、 ``push_hook.py`` という名前のファイルを作り
+``plugins`` サブディレクトリに設置します。
+(プラグインをインストールしていなければ、 ``plugins`` ディレクトリを作る必要があります)。
+
+以上です!次回にpushすると、"The new revno is..."が表示されます。
+もちろん、Pythonのフルパワーを思いとおりにできるので、フックはこれよりもはるかに手が込んでいます。
+これでフックの使い方を理解したので、それらで何をするかはあなたしだいです。
+
+プラグインのコードは2つのことを行います。
+最初に、これは ``push`` が完了した後に実行する関数を定義します。
+(代わりにインスタンスメソッドもしくは呼び出し可能なオブジェクトを使用することもできます。)
+すべてのpushフックは単独の引数 ``push_result`` をとります。
+
+2番目に、プラグインはフックをインストールします。
+最初の引数 ``'post_push'`` はフックがインストールされている場所を特定します。
+2番目の引数はフック自身です。3番目の引数は ``'My post_push hook'`` という名前で、
+これは進行メッセージとエラーメッセージで使用されます。
+
+To reduce the start-up time of Bazaar it is also possible to "lazily" install hooks,
+using the ``bzrlib.hooks.install_lazy_named_hook`` function. This removes the need
+to load the module that contains the hook point just to install the hook. Here's lazy
+version of the example above:
+
+Bazaar のスタートアップ時間を短縮するために、フックを "遅延" インストールすることができます。
+遅延インストールには ``bzrlib.hooks.install_lazy_named_hook`` 関数を使います。
+遅延インストールを使えば、フックをインストールするためだけにフックポイントを含むモジュールを
+ロードする必要がなくなります。
+次の例は、上の例の遅延バージョンです。 ::
+
+ from bzrlib import hooks
+
+ def post_push_hook(push_result):
+ print "The new revno is %d" % push_result.new_revno
+
+
+ hooks.install_lazy_named_hook('bzrlib.branch', 'Branch.hooks',
+ 'post_push', post_push_hook, 'My post_push hook')
+
+
+フックをデバッグする
+---------------------
+
+インストールされたフックの一覧 (と、利用可能なフックポイントの一覧) を表示するには、
+隠しコマンドである ``hooks`` コマンドを使います::
+
+ bzr hooks
+
+
+例: マージプラグイン
+-----------------------
+
+次の例は ``Merger.merge_file_content`` フックのデモのための、完全なプラグインです。
+このプラグインは、 ``*.xml`` の名前のファイルに対する全てのマージに着いて、
+Bazaar がそのマージがクリーンだと判断しても必ず「衝突」状態にします。
+
+``merge_xml.py``::
+
+ """Custom 'merge' logic for *.xml files.
+
+ Always conflicts if both branches have changed the file.
+ """
+
+ from bzrlib.merge import PerFileMerger, Merger
+
+ def merge_xml_files_hook(merger):
+ """Hook to merge *.xml files"""
+ return AlwaysConflictXMLMerger(merger)
+
+ class AlwaysConflictXMLMerger(PerFileMerger):
+
+ def file_matches(self, params):
+ filename = self.get_filename(params, self.merger.this_tree)
+ return filename.endswith('.xml')
+
+ def merge_matching(self, params):
+ return 'conflicted', params.this_lines
+
+ Merger.hooks.install_named_hook(
+ 'merge_file_content', merge_xml_files_hook, '*.xml file merge')
+
+``merge_file_content`` hooks are executed for each file to be merged. For
+a more a complex example look at the ``news_merge`` plugin that's bundled with
+Bazaar in the ``bzrlib/plugins`` directory.
+
+``merge_file_content`` フックは各ファイルがマージされるたびに呼ばれます。
+もっと複雑な例として、 Bazaar の ``bzrlib/plugins`` ディレクトリに同梱されている
+``news_merge`` プラグインも参照してください。
diff --git a/doc/ja/user-guide/http_smart_server.txt b/doc/ja/user-guide/http_smart_server.txt
new file mode 100644
index 0000000..d9ba252
--- /dev/null
+++ b/doc/ja/user-guide/http_smart_server.txt
@@ -0,0 +1,295 @@
+Apache を使って Bazaar サーバーをたてる
+=========================================
+
+このドキュメントでは、 Apache 2.0 と FastCGI, mod_python, mod_wsgi の
+どれかを利用して Bazaar の HTTP スマートサーバーをセットアップする方法を
+説明します。
+
+スマートサーバーに関する詳細な情報とそれを設定する他の方法に関しては、
+`スマートサーバーのドキュメント <server.html>`_ を参照してください。
+
+例
+---
+
+プレーンなHTTPで `/srv/example.com/www/code` を `http://example.com/code/...` として
+すでに公開しているとします。これはbzrのブランチと `/srv/example.com/www/code/branch-one`
+と `/srv/example.com/www/code/my-repo/branch-two` のようなディレクトリを含みます。
+既存のHTTP形式のアクセス権限に加えてリードオンリーのスマートサーバーのアクセス権限を
+これらのディレクトリに提供したい場合を考えます。
+
+Apache 2.0を設定する
+--------------------
+
+FastCGI
+~~~~~~~
+
+最初に、mod_fastcgiを設定します。たとえば次の行をhttpd.confに追加します::
+
+ LoadModule fastcgi_module /usr/lib/apache2/modules/mod_fastcgi.so
+ FastCgiIpcDir /var/lib/apache2/fastcgi
+
+我々の例では、`http://example.com/code` で `/srv/example.com/www/code` をすでに提供しているので
+既存のApacheの設定は次のようになります::
+
+ Alias /code /srv/example.com/www/code
+ <Directory /srv/example.com/www/code>
+ Options Indexes
+ # ...
+ </Directory>
+
+.bzr/smartの形式で終わるURLに対するすべてのリクエストを扱うために
+次のように変更する必要があります::
+
+ Alias /code /srv/example.com/www/code
+ <Directory /srv/example.com/www/code>
+ Options Indexes FollowSymLinks
+ RewriteEngine On
+ RewriteBase /code
+ RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
+ </Directory>
+
+ # bzr-smart.fcgiはDocumentRootの元に存在しないので、実行されるように
+ # AliasはこれをURLの名前空間のエイリアスにする。
+ Alias /srv/example.com/scripts/bzr-smart.fcgi /srv/example.com/scripts/bzr-smart.fcgi
+ <Directory /srv/example.com/scripts>
+ Options ExecCGI
+ <Files bzr-smart.fcgi>
+ SetHandler fastcgi-script
+ </Files>
+ </Directory>
+
+この設定はFastCGIを通して `/code` 内部の `/.bzr/smart` で終わるURLに対する
+Bazaarのスマートサーバーへのリクエストを扱うようにApacheに指示します。
+
+詳細な情報は mod_rewrite_ と mod_fastcgi_ のドキュメントを参照してください。
+
+.. _mod_rewrite: http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
+.. _mod_fastcgi: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
+
+mod_python
+~~~~~~~~~~
+
+最初に、次のようなコードを httpd.conf に追加して mod_python を設定します::
+
+ LoadModule python_module /usr/lib/apache2/modules/mod_python.so
+
+FastCGI と同じ方法で mod_rewrite を用いて書き換えルールを定義します::
+
+ RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
+
+変更は次のようになります::
+
+ RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.py
+
+mod_fastcgi のように、スクリプトがどのように扱われるのかも定義します::
+
+ Alias /srv/example.com/scripts/bzr-smart.py /srv/example.com/scripts/bzr-smart.py
+ <Directory /srv/example.com/scripts>
+ <Files bzr-smart.py>
+ PythonPath "sys.path+['/srv/example.com/scripts']"
+ AddHandler python-program .py
+ PythonHandler bzr-smart::handler
+ </Files>
+ </Directory>
+
+この設定は mod_python を通して `/code` 内部の `/.bzr/smart` で終わるURLに対するリクエストを
+Bazaar のスマートサーバーに渡すように指示します。
+
+注: bzrlib が PATH の中に存在しない場合、次の行を変更する必要があります::
+
+ PythonPath "sys.path+['/srv/example.com/scripts']"
+
+変更後は次のようになります::
+
+ PythonPath "['/path/to/bzr']+sys.path+['/srv/example.com/scripts']"
+
+
+詳細な情報は mod_python_ のドキュメントを参照してください。
+
+.. _mod_python: http://www.modpython.org/
+
+
+mod_wsgi
+~~~~~~~~
+
+最初に、 a2enmod wsgi などで mod_wsgi を有効にしておきます。
+次に、 `.bzr/smart` で終わる全ての URL に対するリクエストを mod_wsgi 経由
+で処理するように設定します。設定例は次のようになります。 ::
+
+ WSGIScriptAliasMatch ^/code/.*/\.bzr/smart$ /srv/example.com/scripts/bzr.wsgi
+
+ #The three next lines allow regular GETs to work too
+ RewriteEngine On
+ RewriteCond %{REQUEST_URI} !^/code/.*/\.bzr/smart$
+ RewriteRule ^/code/(.*/\.bzr/.*)$ /srv/example.com/www/code/$1 [L]
+
+ <Directory /srv/example.com/www/code>
+ WSGIApplicationGroup %{GLOBAL}
+ </Directory>
+
+この設定では、 Apache は `/code` 以下の `/.bzr/smart` で終わる URL に
+対する全てのリクエストを WSGI 経由で Bazaar のスマートサーバーに渡し、
+それ以外の全てのリクエストは Apache が直接扱うようにしています。
+
+詳細は mod_wsgi_ のドキュメントを参照してください。
+
+.. _mod_wsgi: http://code.google.com/p/modwsgi/
+
+Bazaarを設定する
+-----------------
+
+FastCGI
+~~~~~~~
+
+`/srv/example.com/scripts/bzr-smart.fcgi` でスマートサーバーを実行するためにApacheを設定しました。
+これはスマートサーバーを設定するために書く必要のある単なるシンプルなスクリプトで
+サーバーをFastCGIのゲートウェイに結びつけます。次のようになります::
+
+ import fcgi
+ from bzrlib.transport.http import wsgi
+
+ smart_server_app = wsgi.make_app(
+ root='/srv/example.com/www/code',
+ prefix='/code/',
+ path_var='REQUEST_URI',
+ readonly=True,
+ load_plugins=True,
+ enable_logging=True)
+
+ fcgi.WSGIServer(smart_server_app).run()
+
+ `fcgi`のモジュールはhttp://svn.saddi.com/py-lib/trunk/fcgi.pyで見つかります。
+これは flup_ の一部です。
+
+.. _flup: http://www.saddi.com/software/flup/
+
+mod_python
+~~~~~~~~~~
+
+`/srv/example.com/scripts/bzr-smart.py` でスマートサーバーを実行するためにApacheを設定しました。
+これはスマートサーバーを設定するために書く必要のあるシンプルなスクリプトでサーバーをmod_pythonの
+ゲートウェイに結びつけます。次のようになります::
+
+ import modpywsgi
+ from bzrlib.transport.http import wsgi
+
+ smart_server_app = wsgi.make_app(
+ root='/srv/example.com/www/code',
+ prefix='/code/',
+ path_var='REQUEST_URI',
+ readonly=True,
+ load_plugins=True,
+ enable_logging=True)
+
+ def handler(request):
+ """Handle a single request."""
+ wsgi_server = modpywsgi.WSGIServer(smart_server_app)
+ return wsgi_server.run(request)
+
+`modpywsgi` モジュールは
+http://ice.usq.edu.au/svn/ice/trunk/apps/ice-server/modpywsgi.py で見つかります。
+これは pocoo_ の一部でした。 modpywsgi.py を bzr-smart.py と同じディレクトリ
+(すなわち/srv/example.com/scripts/)に設置していることを確認してください。
+
+.. _pocoo: http://dev.pocoo.org/projects/pocoo/
+
+
+mod_wsgi
+~~~~~~~~
+
+We've configured Apache to run the smart server at
+`/srv/example.com/scripts/bzr.wsgi`. This is just a simple script we need
+to write to configure a smart server, and glue it to the WSGI gateway.
+Here's what it looks like::
+
+ from bzrlib.transport.http import wsgi
+
+ def application(environ, start_response):
+ app = wsgi.make_app(
+ root="/srv/example.com/www/code/",
+ prefix="/code",
+ readonly=True,
+ enable_logging=False)
+ return app(environ, start_response)
+
+クライアント
+------------
+
+これで `bzr+http://` 形式のURLやただの `http://` のURLを利用できます::
+
+ bzr log bzr+http://example.com/code/my-branch
+
+プレーンなHTTP形式のアクセスも持続します::
+
+ bzr log http://example.com/code/my-branch
+
+
+高度な設定
+-----------
+
+BazaarのHTTPスマートサーバーはWSGIアプリケーションなので、
+WSGI標準に準拠するサードパーティのWSGIのミドルウェアもしくはサーバーで利用できます。
+唯一の要件は以下のとおりです:
+
+ * `SmartWSGIApp` をコンストラクトするためには、それが提供する **root transport** を指定する必要があります。
+ * それぞれのリクエストの `environ` dict は **'bzrlib.relpath'** 変数の設定を持たなければなりません。
+
+この例で使われている `make_app` ヘルパーは それに渡される `root` パスに基づいたトランスポートを伴う
+`SmartWSGIApp` をコンストラクトし、引数 `prefix` と`path_var` に基づくそれぞれのリクエストに対する
+ `bzrlib.relpath` を算出します。
+上記の例において、これは (Apacheによって設定される)'REQUEST_URI' を取り、接頭辞の '/code/' と接尾辞の '/.bzr/smart'
+をはぎ取り、それを 'bzrlib.relpath' として設定するので、 '/code/foo/bar/.bzr/smart' に対するリクエストは
+'foo/bzr' の 'bzrlib.relpath' になります。
+
+`SmartWSGIApp` を直接コンストラクトすることで、ローカルではないトランスポートに対して
+スマートサーバーを設定するもしくは任意任意のパスの変換を行うことは可能です。
+詳細な情報に関しては `bzrlib.transport.http.wsgi` のdocstringsと `WSGI標準`_ を参照してください。
+
+.. _WSGI標準: http://www.python.org/dev/peps/pep-0333/
+
+
+HTTP スマートサーバー経由で push する
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+HTTP スマートサーバーを通してデータをプッシュすることは可能です。
+これを行うための最も簡単な方法は、 ``wsgi.make_app()`` コールに ``readonly=False`` を
+提供するだけです。ただし、スマートプロトコルは認証機能が含まれないので注意してください。
+書き込みのサポートを有効にする場合、
+実際にシステム上のデータを書き込みできる人を制限するために、 ``.bzr/smart``
+URLへの権限を制限するとよいでしょう。例えば Apache で次のような設定を
+します。 ::
+
+ <Location /code>
+ AuthType Basic
+ AuthName "example"
+ AuthUserFile /srv/example.com/conf/auth.passwd
+ <LimitExcept GET>
+ Require valid-user
+ </LimitExcept>
+ </Location>
+
+
+現時点では、同じURLに対して読み込み限定の人と読み込みと書き込みの人を
+分けることはできません。
+(認証を行う)HTTPレイヤーにおいて、すべては単なるPOSTリクエストだからです。
+しかしながら、HTTPSアクセスの場合に認証が必要な書き込みサーバーを使い、
+プレーンなHTTPは読み込み限定のアクセスを許可することはできます。
+
+HTTPS サイトに対してアクセスしたときに bzr が次のようなエラーを表示する
+場合::
+
+ bzr: ERROR: Connection error: curl connection error (server certificate verification failed.
+ CAfile:/etc/ssl/certs/ca-certificates.crt CRLfile: none)
+
+You can workaround it by using ``https+urllib`` rather than ``http`` in your
+URL, or by uninstalling pycurl. See `bug 82086`_ for more details.
+
+URL に ``https`` の代わりに ``https+urllib`` を使うことで問題を回避
+できます。
+詳細については `bug 82086`_ を参照してください。
+
+.. _bug 82086: https://bugs.launchpad.net/bzr/+bug/82086
+
+
+..
+ vim: ft=rst tw=74 et
diff --git a/doc/ja/user-guide/images/workflows_centralized.png b/doc/ja/user-guide/images/workflows_centralized.png
new file mode 100644
index 0000000..f964fe0
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_centralized.png
Binary files differ
diff --git a/doc/ja/user-guide/images/workflows_centralized.svg b/doc/ja/user-guide/images/workflows_centralized.svg
new file mode 100644
index 0000000..4a09de0
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_centralized.svg
@@ -0,0 +1,1542 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_centralized.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_centralized.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.4142136"
+ inkscape:cx="536.99132"
+ inkscape:cy="369.73871"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1024"
+ inkscape:window-height="712"
+ inkscape:window-x="-4"
+ inkscape:window-y="-4" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr checkout</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(492.85715,-2.8571472)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.71429"
+ y="191.52307"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="777.71429"
+ y="191.52307">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="819.5625"
+ y="191.21948"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="819.5625"
+ y="191.21948">bzr update</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.29065037;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 539.95542,466.93556 L 415.85387,476.71718 L 426.49116,461.93102 L 358.1094,466.70812 C 358.1094,466.70812 347.47211,481.94916 346.96566,481.94916 C 346.45858,481.94916 322.14533,462.15846 322.14533,462.15846 C 322.14533,462.15846 379.38334,441.45772 379.88978,441.45772 C 379.38334,441.00284 369.25249,456.01673 369.25249,456.24417 L 448.27282,451.23935 L 437.63489,466.48068 L 551.09912,456.92649 L 539.95542,466.93556 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(51.511043,348.5966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="334.36819"
+ y="540.97681"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="334.36819"
+ y="540.97681">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="369.5625"
+ y="544.09448"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="369.5625"
+ y="544.09448">bzr commit</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ja/user-guide/images/workflows_gatekeeper.png b/doc/ja/user-guide/images/workflows_gatekeeper.png
new file mode 100644
index 0000000..eded8a4
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_gatekeeper.png
Binary files differ
diff --git a/doc/ja/user-guide/images/workflows_gatekeeper.svg b/doc/ja/user-guide/images/workflows_gatekeeper.svg
new file mode 100644
index 0000000..6490454
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_gatekeeper.svg
@@ -0,0 +1,2137 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_gatekeeper.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_manualpqm.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient7932"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7934"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7936"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7938"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7940"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7942"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7944"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient7946"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7948"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7950"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient7952"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7954"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7956"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7958"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7960"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7962"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient7964"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7966"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient7968"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7990"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <radialGradient
+ xlink:href="#linearGradient1861"
+ r="26.285225"
+ inkscape:collect="always"
+ id="radialGradient1887"
+ fy="44.906904"
+ fx="34.609807"
+ cy="45.317611"
+ cx="33.865884"
+ gradientTransform="scale(1.3025634,0.767717)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1861"
+ r="27.313507"
+ inkscape:collect="always"
+ id="radialGradient1885"
+ fy="96.522109"
+ fx="44.745902"
+ cy="96.948882"
+ cx="45.838441"
+ gradientTransform="scale(1.0963096,0.9121511)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="69.990188"
+ y1="60.176033"
+ xlink:href="#linearGradient1864"
+ x2="54.084046"
+ x1="51.210938"
+ inkscape:collect="always"
+ id="linearGradient1883"
+ gradientTransform="scale(1.2343409,0.8101489)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1858">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop1859" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop1860" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1861">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop1862" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1863" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1864">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop1865" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1866" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1867">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop1868" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1869" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11180">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop11182" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11184" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11174">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop11176" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11178" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11168">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop11170" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11172" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11162">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop11164" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop11166" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="559.94128"
+ inkscape:cy="472.46874"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1416"
+ inkscape:window-height="825"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,39.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,227.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(635.63525,491.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="73.4375"
+ y="510.12573"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="73.4375"
+ y="510.12573">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(466.18527,201.5491)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="751.04242"
+ y="395.37573"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="751.04242"
+ y="395.37573">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="778.89062"
+ y="392.32886"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="778.89062"
+ y="392.32886"
+ id="tspan2963">make changes</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.52894235;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 578.13978,492.35651 L 518.11306,536.64644 L 515.93459,528.2361 L 482.53728,552.4378 C 482.53728,552.4378 484.9546,560.99862 484.68867,561.16617 C 484.42242,561.33391 461.26447,562.83001 461.26447,562.83001 C 461.26447,562.83001 480.44933,537.04707 480.71524,536.87954 C 480.21048,536.89659 482.77445,545.21473 482.89387,545.28997 L 521.75768,517.49359 L 524.17482,526.05472 L 578.73553,485.35896 L 578.13978,492.35651 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(449.56027,418.37723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="732.41742"
+ y="611.97729"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="732.41742"
+ y="611.97729">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="768.26562"
+ y="608.23511"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="768.26562"
+ y="608.23511">request merge</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="75.5625"
+ y="228.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="75.5625"
+ y="228.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="556.98438"
+ y="165.64139"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="556.98438"
+ y="165.64139">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-477.33182,37.826027)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.0657387,0,0,1.0382501,-36.482679,-19.544354)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.27460909;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path7875"
+ d="M 313.49127,554.98551 L 266.8349,508.88833 L 275.69462,507.21539 L 250.19978,481.56811 C 250.19978,481.56811 241.18156,483.42447 241.00507,483.22026 C 240.82835,483.0158 239.25232,465.23179 239.25232,465.23179 C 239.25232,465.23179 266.41286,479.96469 266.58935,480.16889 C 266.57138,479.78127 257.8088,481.75026 257.72954,481.84196 L 287.01109,511.6872 L 277.99254,513.54344 L 320.8627,555.44302 L 313.49127,554.98551 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <g
+ id="g7884"
+ transform="translate(322.22009,479.97324)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient7932);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path7886"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient7934);fill-opacity:1"
+ id="g7888">
+ <path
+ style="fill:url(#linearGradient7936);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path7890"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient7938);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path7892"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient7940);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path7894"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient7942);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient7944);stroke-width:1.44734821pt"
+ id="rect7896"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient7946);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path7898"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient7948);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path7900"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient7950);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect7902"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient7952);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient7954);stroke-width:1.4649456pt"
+ id="rect7904"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient7956);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path7906"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g7908">
+ <path
+ style="fill:url(#linearGradient7958);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path7910"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient7960);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path7912"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient7962);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path7914"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient7964);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path7916"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient7966);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path7918"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient7968);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path7920"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient7990);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path7922"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text7924"><tspan
+ id="tspan7926">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text7928"><tspan
+ id="tspan7930">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g11201"
+ transform="translate(224.98935,560.87966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11204"
+ d="M 61.208646,74.540863 C 65.958047,79.724425 68.980394,89.011639 75.672733,89.01164 C 82.14919,87.211791 83.012718,71.805094 83.876245,68.493375 C 76.536261,73.532948 68.980395,76.412704 61.208646,74.540863 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,-0.8485902,18.11889)"
+ style="fill:#ebd5bb;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path11206"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#354b63;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path11208"
+ d="M 32.210275,101.34753 C 31.819634,126.54379 96.449036,129.42515 96.292736,101.34753 C 97.837516,79.018786 86.732289,66.323086 83.972618,68.481556 C 82.571377,69.577533 82.050742,93.917319 72.58281,88.318677 C 67.97993,85.596878 62.831472,75.141814 60.578865,74.794949 C 57.17979,74.271545 50.671042,71.519447 44.693328,66.368738 C 43.125035,65.017418 32.739724,78.907727 32.210275,101.34753 z " />
+ <path
+ style="fill:#7e5429;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccscc"
+ id="path14564"
+ d="M 67.304802,16.686453 C 54.985668,-4.2976037 31.742548,13.847204 34.832083,38.13111 C 28.606909,39.936495 13.38594,55.735942 54.610465,51.217079 C 72.973357,49.204214 127.11969,28.718598 84.679736,22.863615 C 78.797006,1.2972292 67.040662,6.1031815 67.304802,16.686453 z " />
+ <path
+ style="fill:url(#linearGradient1883);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1879"
+ d="M 89.582928,41.074792 C 78.886738,46.748497 62.561318,51.815798 53.926678,52.762292 C 47.018518,53.519536 42.160188,53.578455 38.114178,53.356042 C 39.550848,66.152312 50.849068,76.168541 64.707928,76.168542 C 79.538378,76.168542 91.582928,64.747093 91.582928,50.668542 C 91.582928,47.276803 90.850878,44.035951 89.582928,41.074792 z " />
+ <path
+ style="fill:url(#radialGradient1885);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1884"
+ d="M 43.031249,70.1875 C 35.995246,80.448202 32.902215,93.581638 34.156249,105.875 C 40.334493,118.62839 56.831543,120.43683 69.499999,119.875 C 80.494576,119.32475 94.949065,113.14258 93.695531,100.00002 C 93.939855,90.023763 92.261916,78.780004 84.874999,71.5 C 82.650684,78.396104 83.536195,89.443626 74.999999,91.84375 C 65.062996,91.017122 64.05284,76.914438 54.283675,75.750529 C 50.352102,75.051855 46.009593,69.547093 43.031249,70.1875 z " />
+ <path
+ style="fill:url(#radialGradient1887);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1886"
+ d="M 51.968749,10.15625 C 40.703741,13.843837 36.038494,27.433868 37.531249,38.375 C 35.900906,41.584912 25.71302,45.254989 31.843749,49.03125 C 53.068339,53.154256 75.12687,46.221276 93.715523,36.077723 C 100.42684,33.740896 99.810666,26.846559 92.384918,26.66513 C 86.324151,26.558371 81.674394,23.81643 81.165374,17.307044 C 79.826948,13.582045 74.107596,6.6890987 71.01108,12.623276 C 71.073069,19.511996 65.891703,20.102559 63.230392,14.042893 C 60.468574,10.851605 56.135557,9.1882781 51.968749,10.15625 z " />
+ </g>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2488"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(82.857147,474.9866)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="365.71429"
+ y="668.60229"
+ id="text2490"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2492"
+ x="365.71429"
+ y="668.60229">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="401.5625"
+ y="665.76636"
+ id="text2494"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2496"
+ x="401.5625"
+ y="665.76636">accept or reject</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ja/user-guide/images/workflows_localcommit.png b/doc/ja/user-guide/images/workflows_localcommit.png
new file mode 100644
index 0000000..f6d4f83
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_localcommit.png
Binary files differ
diff --git a/doc/ja/user-guide/images/workflows_localcommit.svg b/doc/ja/user-guide/images/workflows_localcommit.svg
new file mode 100644
index 0000000..2e7ad85
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_localcommit.svg
@@ -0,0 +1,1575 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_localcommit.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_localcommit.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient8493"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient8491"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient8485">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop8487" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop8489" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.70710678"
+ inkscape:cx="503.09779"
+ inkscape:cy="201.79714"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1024"
+ inkscape:window-height="712"
+ inkscape:window-x="-4"
+ inkscape:window-y="-4" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="763.75"
+ y="188.09448"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="763.75"
+ y="188.09448">bzr commit --local</tspan><tspan
+ sodipodi:role="line"
+ x="763.75"
+ y="228.09448"
+ id="tspan7922" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="801.4375"
+ y="609.46948"
+ id="text7881"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan7883"
+ x="801.4375"
+ y="609.46948">bzr unbind</tspan><tspan
+ sodipodi:role="line"
+ x="801.4375"
+ y="641.46948"
+ id="tspan8507">bzr commit</tspan><tspan
+ sodipodi:role="line"
+ x="801.4375"
+ y="673.46948"
+ id="tspan8511">bzr bind</tspan></text>
+ <g
+ id="g7903"
+ transform="translate(21.8125,50.285718)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path7897"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text7899"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan7901"
+ sodipodi:role="line">1</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="351.375"
+ y="272.69269"
+ id="text7908"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan7910"
+ x="351.375"
+ y="272.69269">bzr checkout</tspan></text>
+ <g
+ id="g7912"
+ transform="translate(438.71429,-31.85714)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path7914"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text7916"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan7918"
+ sodipodi:role="line">2</tspan></text>
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.58159733;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path8495"
+ d="M 530.64409,443.90791 L 411.93077,455.56731 L 422.10621,437.94266 L 356.69344,443.63682 C 356.69344,443.63682 346.51796,461.80368 346.0335,461.80368 C 345.54844,461.80368 322.2908,438.21377 322.2908,438.21377 C 322.2908,438.21377 377.0437,413.53911 377.52817,413.53911 C 377.0437,412.99691 367.35272,430.89301 367.35272,431.16411 L 442.94217,425.19852 L 432.76613,443.36572 L 541.30393,431.97742 L 530.64409,443.90791 z " />
+ <g
+ id="g8497"
+ transform="translate(446.57144,390.28572)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path8499"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text8501"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan8503"
+ sodipodi:role="line">2</tspan></text>
+ </g>
+ <g
+ id="g8513"
+ transform="translate(59.142865,311.71429)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path8515"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text8517"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan8519"
+ sodipodi:role="line">3</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="389.375"
+ y="534.40698"
+ id="text8525"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan8527"
+ x="389.375"
+ y="534.40698">bzr commit</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ja/user-guide/images/workflows_peer.png b/doc/ja/user-guide/images/workflows_peer.png
new file mode 100644
index 0000000..d1cfa71
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_peer.png
Binary files differ
diff --git a/doc/ja/user-guide/images/workflows_peer.svg b/doc/ja/user-guide/images/workflows_peer.svg
new file mode 100644
index 0000000..f68a774
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_peer.svg
@@ -0,0 +1,1589 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_peer.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_peer.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="536.99132"
+ inkscape:cy="369.73871"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1759"
+ inkscape:window-height="875"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ id="g5256"
+ transform="translate(601.5744,309.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(541.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(111.5744,317.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,300.80614,215.0989)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 357.16674,263.66524 L 470.27399,251.12251 L 460.57906,270.08242 L 522.9028,263.95688 C 522.9028,263.95688 532.59773,244.41369 533.05931,244.41369 C 533.52148,244.41369 555.68079,269.79078 555.68079,269.79078 C 555.68079,269.79078 503.51355,296.33479 503.05197,296.33479 C 503.51355,296.91808 512.74689,277.66616 512.74689,277.37453 L 440.72705,283.79207 L 450.42255,264.24852 L 347.01023,276.4996 L 357.16674,263.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="635.5625"
+ y="201.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="635.5625"
+ y="201.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(318.85715,7.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="601.71429"
+ y="199.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="601.71429"
+ y="199.52307">2</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.49513507;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 426.28539,558.28183 L 482.38891,565.59894 L 477.58003,554.5382 L 508.49388,558.1117 C 508.49388,558.1117 513.30276,569.51271 513.53172,569.51271 C 513.76096,569.51271 524.75243,554.70834 524.75243,554.70834 C 524.75243,554.70834 498.87641,539.22321 498.64746,539.22321 C 498.87641,538.88294 503.45634,550.11403 503.45634,550.28417 L 467.73303,546.54033 L 472.54219,557.94156 L 421.24757,550.79458 L 426.28539,558.28183 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-194.48896,372.41254)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="87.591393"
+ y="566.02826"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="87.591393"
+ y="566.02826">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="119.03906"
+ y="543.19232"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="119.03906"
+ y="543.19232">merge changes</tspan><tspan
+ sodipodi:role="line"
+ x="119.03906"
+ y="583.19232"
+ id="tspan2716">from peer</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2670"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-187.14285,5.361605)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="94.539062"
+ y="198.97729"
+ id="text2672"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2674"
+ x="94.539062"
+ y="198.97729">1</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="129.5625"
+ y="195.43823"
+ id="text2676"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2678"
+ x="129.5625"
+ y="195.43823">start project</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2680"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-20.189728,217.62723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="261.83594"
+ y="411.22729"
+ id="text2682"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2684"
+ x="261.83594"
+ y="411.22729">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="294.51562"
+ y="388.40698"
+ id="text2686"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2688"
+ x="294.51562"
+ y="388.40698">record</tspan><tspan
+ sodipodi:role="line"
+ x="294.51562"
+ y="428.40698"
+ id="tspan2712">changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2690"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(321.8001,372.41254)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="603.88049"
+ y="566.02826"
+ id="text2692"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2694"
+ x="603.88049"
+ y="566.02826">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="635.32812"
+ y="543.19232"
+ id="text2696"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2698"
+ x="635.32812"
+ y="543.19232">merge changes</tspan><tspan
+ sodipodi:role="line"
+ x="635.32812"
+ y="583.19232"
+ id="tspan2718">from peer</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2700"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(462.85715,216.65848)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="744.88281"
+ y="410.25854"
+ id="text2702"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2704"
+ x="744.88281"
+ y="410.25854">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.5625"
+ y="387.43823"
+ id="text2706"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2708"
+ x="777.5625"
+ y="387.43823">record</tspan><tspan
+ sodipodi:role="line"
+ x="777.5625"
+ y="427.43823"
+ id="tspan2714">changes</tspan></text>
+ <path
+ inkscape:export-ydpi="41.964157"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ d="M 515.71461,505.61603 L 459.61109,512.93314 L 464.41997,501.8724 L 433.50612,505.4459 C 433.50612,505.4459 428.69724,516.84691 428.46828,516.84691 C 428.23904,516.84691 417.24757,502.04254 417.24757,502.04254 C 417.24757,502.04254 443.12359,486.55741 443.35254,486.55741 C 443.12359,486.21714 438.54366,497.44823 438.54366,497.61837 L 474.26697,493.87453 L 469.45781,505.27576 L 520.75243,498.12878 L 515.71461,505.61603 z "
+ id="path2710"
+ sodipodi:nodetypes="cccccccccccc"
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.49513507;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1" />
+ </g>
+</svg>
diff --git a/doc/ja/user-guide/images/workflows_pqm.png b/doc/ja/user-guide/images/workflows_pqm.png
new file mode 100644
index 0000000..3cfe139
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_pqm.png
Binary files differ
diff --git a/doc/ja/user-guide/images/workflows_pqm.svg b/doc/ja/user-guide/images/workflows_pqm.svg
new file mode 100644
index 0000000..8c6dcbf
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_pqm.svg
@@ -0,0 +1,1794 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_pqm.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_pqm.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7934"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ id="linearGradient1858">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop1859" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop1860" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1861">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop1862" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1863" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1864">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop1865" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1866" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1867">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop1868" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1869" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11180">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop11182" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11184" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11174">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop11176" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11178" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11168">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop11170" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11172" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11162">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop11164" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop11166" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="559.94128"
+ inkscape:cy="392.13154"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1416"
+ inkscape:window-height="825"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2791"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(562.85715,227.14285)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="844.88281"
+ y="420.74292"
+ id="text2793"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2795"
+ x="844.88281"
+ y="420.74292">3</tspan></text>
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,39.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,227.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(593.63525,509.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,417.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,874.16045,452.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="92.546875"
+ y="509.71948"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="92.546875"
+ y="509.71948">Server</tspan><tspan
+ sodipodi:role="line"
+ x="92.546875"
+ y="569.71948"
+ id="tspan2803">(PQM)</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(558.85715,89.5491)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="841.25"
+ y="283.37573"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="841.25"
+ y="283.37573">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="874.89062"
+ y="264.32886"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="874.89062"
+ y="264.32886"
+ id="tspan2788">make</tspan><tspan
+ sodipodi:role="line"
+ x="874.89062"
+ y="304.32886"
+ id="tspan2815">changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(449.56027,432.37723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="732.41742"
+ y="625.97729"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="732.41742"
+ y="625.97729">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="768.26562"
+ y="622.23511"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="768.26562"
+ y="622.23511">accept or reject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="75.5625"
+ y="228.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="75.5625"
+ y="228.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="556.98438"
+ y="165.64139"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="556.98438"
+ y="165.64139">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-477.33182,37.826027)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.0657387,0,0,1.0382501,-36.482679,-19.544354)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <g
+ id="g11201"
+ transform="translate(224.98935,560.87966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2488"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(44.857147,386.9866)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="327.71429"
+ y="580.60229"
+ id="text2490"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2492"
+ x="327.71429"
+ y="580.60229">5</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="363.5625"
+ y="577.76636"
+ id="text2494"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2496"
+ x="363.5625"
+ y="577.76636">request merge</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path2801"
+ d="M 530.83326,472.52373 L 417.72601,485.06646 L 427.42094,466.10655 L 365.0972,472.23209 C 365.0972,472.23209 355.40227,491.77528 354.94069,491.77528 C 354.47852,491.77528 332.31921,466.39819 332.31921,466.39819 C 332.31921,466.39819 384.48645,439.85418 384.94803,439.85418 C 384.48645,439.27089 375.25311,458.52281 375.25311,458.81444 L 447.27295,452.3969 L 437.57745,471.94045 L 540.98977,459.68937 L 530.83326,472.52373 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="878.89062"
+ y="396.40698"
+ id="text2811"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="878.89062"
+ y="396.40698"
+ id="tspan2813">request</tspan><tspan
+ sodipodi:role="line"
+ x="878.89062"
+ y="436.40698"
+ id="tspan2817">review</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ja/user-guide/images/workflows_shared.png b/doc/ja/user-guide/images/workflows_shared.png
new file mode 100644
index 0000000..331feb9
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_shared.png
Binary files differ
diff --git a/doc/ja/user-guide/images/workflows_shared.svg b/doc/ja/user-guide/images/workflows_shared.svg
new file mode 100644
index 0000000..762155e
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_shared.svg
@@ -0,0 +1,1594 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_shared.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_shared.png"
+ inkscape:export-xdpi="49.419998"
+ inkscape:export-ydpi="49.419998">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.8"
+ inkscape:cx="578.40513"
+ inkscape:cy="404.22798"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1405"
+ inkscape:window-height="869"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(492.85715,-2.8571472)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.71429"
+ y="191.52307"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="777.71429"
+ y="191.52307">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="819.5625"
+ y="179.59448"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="819.5625"
+ y="179.59448">bzr pull</tspan><tspan
+ sodipodi:role="line"
+ x="819.5625"
+ y="219.59448"
+ id="tspan2963">bzr merge</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.29065037;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 539.95542,466.93556 L 415.85387,476.71718 L 426.49116,461.93102 L 358.1094,466.70812 C 358.1094,466.70812 347.47211,481.94916 346.96566,481.94916 C 346.45858,481.94916 322.14533,462.15846 322.14533,462.15846 C 322.14533,462.15846 379.38334,441.45772 379.88978,441.45772 C 379.38334,441.00284 369.25249,456.01673 369.25249,456.24417 L 448.27282,451.23935 L 437.63489,466.48068 L 551.09912,456.92649 L 539.95542,466.93556 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(51.511043,348.5966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="334.36819"
+ y="540.97681"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="334.36819"
+ y="540.97681">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="369.5625"
+ y="544.09448"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="369.5625"
+ y="544.09448">bzr commit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="61.5625"
+ y="240.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="61.5625"
+ y="240.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="563.43756"
+ y="582.09442"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="563.43756"
+ y="582.09442">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006169;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-501.33182,49.826027)" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.1405493,0,0,1.0364644,-57.067817,396.76108)" />
+ </g>
+</svg>
diff --git a/doc/ja/user-guide/images/workflows_single.png b/doc/ja/user-guide/images/workflows_single.png
new file mode 100644
index 0000000..772909a
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_single.png
Binary files differ
diff --git a/doc/ja/user-guide/images/workflows_single.svg b/doc/ja/user-guide/images/workflows_single.svg
new file mode 100644
index 0000000..1d312a2
--- /dev/null
+++ b/doc/ja/user-guide/images/workflows_single.svg
@@ -0,0 +1,1079 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_single.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.4142136"
+ inkscape:cx="536.99132"
+ inkscape:cy="529.01021"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1465"
+ inkscape:window-height="896"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ id="g5256"
+ transform="translate(631.5744,227.66157)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="345.5625"
+ y="218.05542"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ x="345.5625"
+ y="218.05542"
+ id="tspan2399">create project</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,24.174103)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.53906"
+ y="217.78979"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="314.53906"
+ y="217.78979">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(33.388397,76.658478)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="315.78125"
+ y="270.48511"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="315.78125"
+ y="270.48511">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="344.92188"
+ y="267.43823"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="344.92188"
+ y="267.43823">record changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,128.5416)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.88281"
+ y="322.14166"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="314.88281"
+ y="322.14166">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="346.9086"
+ y="319.32135"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="346.9086"
+ y="319.32135">browse history</tspan></text>
+ <flowRoot
+ xml:space="preserve"
+ id="flowRoot2405"><flowRegion
+ id="flowRegion2407"><rect
+ id="rect2409"
+ width="274.35742"
+ height="94.045197"
+ x="293.44931"
+ y="485.2934" /></flowRegion><flowPara
+ id="flowPara2411"></flowPara></flowRoot> <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2427"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,180.5416)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.9375"
+ y="374.15729"
+ id="text2429"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2431"
+ x="314.9375"
+ y="374.15729">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="346.9086"
+ y="371.32135"
+ id="text2433"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2435"
+ x="346.9086"
+ y="371.32135">package release</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ja/user-guide/index-plain.txt b/doc/ja/user-guide/index-plain.txt
new file mode 100644
index 0000000..bb3015d
--- /dev/null
+++ b/doc/ja/user-guide/index-plain.txt
@@ -0,0 +1,120 @@
+####################
+Bazaarユーザーガイド
+####################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+.. contents:: :depth: 3
+
+
+紹介
+############
+
+.. include:: introducing_bazaar.txt
+.. include:: core_concepts.txt
+.. include:: bazaar_workflows.txt
+
+
+始める
+###############
+
+.. include:: installing_bazaar.txt
+.. include:: entering_commands.txt
+.. include:: getting_help.txt
+.. include:: configuring_bazaar.txt
+.. include:: using_aliases.txt
+.. include:: plugins.txt
+.. include:: zen.txt
+
+
+個人用途のバージョン管理
+########################
+
+.. include:: solo_intro.txt
+.. include:: starting_a_project.txt
+.. include:: controlling_registration.txt
+.. include:: reviewing_changes.txt
+.. include:: recording_changes.txt
+.. include:: browsing_history.txt
+.. include:: releasing_a_project.txt
+.. include:: undoing_mistakes.txt
+
+
+同僚と共有する
+##################
+
+.. include:: partner_intro.txt
+.. include:: branching_a_project.txt
+.. include:: merging_changes.txt
+.. include:: resolving_conflicts.txt
+.. include:: annotating_changes.txt
+
+
+集中スタイルの、チームコラボレーション
+############################################
+
+.. include:: central_intro.txt
+.. include:: publishing_a_branch.txt
+.. include:: using_checkouts.txt
+.. include:: working_offline_central.txt
+.. include:: reusing_a_checkout.txt
+
+
+分散スタイルの、チームコラボレーション
+########################################
+
+.. include:: distributed_intro.txt
+.. include:: organizing_branches.txt
+.. include:: using_gatekeepers.txt
+.. include:: sending_changes.txt
+
+
+その他のトピック
+####################
+
+.. include:: part2_intro.txt
+.. include:: adv_merging.txt
+.. include:: shelving_changes.txt
+.. include:: filtered_views.txt
+.. include:: stacked.txt
+.. include:: server.txt
+.. include:: hooks.txt
+.. include:: version_info.txt
+
+
+人気のあるプラグインの手短なツアー
+####################################
+
+.. include:: bzrtools_plugin.txt
+.. include:: svn_plugin.txt
+.. include later looms_plugin.txt
+
+
+Bazaarを環境に統合する
+#######################
+
+.. include:: web_browsing.txt
+.. include later - file_explorers.txt
+.. include later - desktop_integration.txt
+.. include later - editors_and_ides.txt
+.. include later - email.txt
+.. include:: bug_trackers.txt
+
+
+付録
+#####
+
+.. include:: specifying_revisions.txt
+.. include:: organizing_your_workspace.txt
+.. include:: shared_repository_layouts.txt
+.. include:: setting_up_email.txt
+.. include:: http_smart_server.txt
+.. include:: writing_a_plugin.txt
+.. include:: licence.txt
+
+.. |--| unicode:: U+2014
+
diff --git a/doc/ja/user-guide/index.txt b/doc/ja/user-guide/index.txt
new file mode 100644
index 0000000..b3b66cc
--- /dev/null
+++ b/doc/ja/user-guide/index.txt
@@ -0,0 +1,141 @@
+####################
+Bazaarユーザーガイド
+####################
+
+.. Please mark sections in included files as following:
+.. level 1 ========
+.. level 2 --------
+.. level 3 ~~~~~~~~
+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
+
+紹介
+#####
+
+.. toctree::
+ :maxdepth: 1
+
+ introducing_bazaar
+ core_concepts
+ bazaar_workflows
+
+
+始める
+#######
+
+.. toctree::
+ :maxdepth: 1
+
+ installing_bazaar
+ entering_commands
+ getting_help
+ configuring_bazaar
+ using_aliases
+ plugins
+ zen
+
+
+個人用途のバージョン管理
+#########################
+
+.. toctree::
+ :maxdepth: 1
+
+ solo_intro
+ starting_a_project
+ controlling_registration
+ reviewing_changes
+ recording_changes
+ browsing_history
+ releasing_a_project
+ undoing_mistakes
+
+
+同僚と共有する
+##############
+
+.. toctree::
+ :maxdepth: 1
+
+ partner_intro
+ branching_a_project
+ merging_changes
+ resolving_conflicts
+ annotating_changes
+
+
+集中スタイルの、チームコラボレーション
+#######################################
+
+.. toctree::
+ :maxdepth: 1
+
+ central_intro
+ publishing_a_branch
+ using_checkouts
+ working_offline_central
+ reusing_a_checkout
+
+
+分散スタイルの、チームコラボレーション
+#######################################
+
+.. toctree::
+ :maxdepth: 1
+
+ distributed_intro
+ organizing_branches
+ using_gatekeepers
+ sending_changes
+
+
+その他のトピック
+#################
+
+.. toctree::
+ :maxdepth: 1
+
+ part2_intro
+ adv_merging
+ shelving_changes
+ filtered_views
+ stacked
+ server
+ hooks
+ version_info
+
+
+人気のあるプラグインの手短なツアー
+####################################
+
+.. toctree::
+ :maxdepth: 1
+
+ bzrtools_plugin
+ svn_plugin
+
+
+Bazaarを環境に統合する
+#######################
+
+.. toctree::
+ :maxdepth: 1
+
+ web_browsing
+ bug_trackers
+
+
+付録
+#####
+
+.. toctree::
+ :maxdepth: 1
+
+ specifying_revisions
+ organizing_your_workspace
+ shared_repository_layouts
+ setting_up_email
+ http_smart_server
+ writing_a_plugin
+ licence
+
+.. |--| unicode:: U+2014
diff --git a/doc/ja/user-guide/installing_bazaar.txt b/doc/ja/user-guide/installing_bazaar.txt
new file mode 100644
index 0000000..8819afe
--- /dev/null
+++ b/doc/ja/user-guide/installing_bazaar.txt
@@ -0,0 +1,102 @@
+Bazaarをインストールする
+=========================
+
+GNU/Linux
+----------
+
+Bazaar のパッケージは Ubuntu/Debian, Red Hat と Gentoo を含む人気のある
+大抵の GNU/Linux ディストリビューションで利用できます。
+最新の手引きは http://wiki.bazaar.canonical.com/Download を参照してください。
+
+Windows
+-------
+
+Windowsユーザーは、Bazaarのコアパッケージと一緒に必要な前提要件と
+いくつかの便利なプラグインを含むインストーラが利用できます。
+最新の手引きは http://wiki.bazaar.canonical.com/Download を参照してください。
+
+注: Windows上でCygwinを動かしている場合、Cygwin用のBazaarパッケージを\
+Windows版の代わりに使わなければなりません。
+
+他のオペレーティングシステム
+-----------------------------
+
+BazaarのパッケージはLinuxとWindowsだけでなく、Mac OS X, FreeBSD, Solaris\
+を含む広い範囲のオペレーティングシステムで利用可能です。
+最新の手引きに関しては http://bazaar-vcs.org/Download を参照してください。
+
+
+ゼロからインストールする
+-------------------------
+
+予めビルドされたパッケージよりもソースからBazaarをビルドしたい場合、\
+手順は次のとおりです:
+
+ 1. まだインストールしていなければ、バージョン2.4以降のPythonをインストールします。
+
+ 2. http://wiki.bazaar.canonical.com/Download もしくは Launchpad
+ (https://launchpad.net/~bzr/)から ``bazaar-xxx.tar.gz`` ファイル
+ (xxxはバージョン番号)をダウンロードします。
+
+ 3. tar、WinZipもしくは同等のコマンドを用いてアーカイブを解凍します。
+
+ 4. 作成されたディレクトリをPATHに登録します。
+
+インストールが成功したことを確認するために、次のように **bzr** コマンドを試します::
+
+ bzr version
+
+このコマンドによってインストールされているBazaarのバージョンが表示されます。
+このコマンドが動作しない場合、開発者が正常な動作の手助けをできるように
+EメールかIRCを通して開発者に連絡をして頂くようお願いします。
+
+
+site-wide な場所にインストールする
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ディレクトリにPATHを設定する代わりに、次のコマンドでにbzrを\
+インストールすることができます。::
+
+ python setup.py install
+
+もしあなたがコンパイラやPythonの開発ツールを持っていない場合、
+bzrは全ての拡張モジュールに対して(遅い)pure-pythonの実装を提供します。
+次のコマンドを使って拡張モジュールのコンパイルなしにインストールできます::
+
+ python setup.py install build_ext --allow-python-fallback
+
+
+開発バージョンを稼働させる
+---------------------------
+
+Bazaarの最新の開発バージョンを常に利用したい場合があります。
+バグの危険性が増すので大半のユーザーにはお勧めできないことに注意してください。
+一方で、開発バージョンは(開発プロセスのおかげで)非常に安定しているので、
+これを動かすことで、バグと改善内容のための変更内容を開発者に送ることが楽になります。
+より多くの人が最新のソフトウェアをテストすることで開発者の手助けにもなります。
+
+従うべき手順は次のとおりです:
+
+ 1. 上記の方法の1つを利用してBazaarをインストールする。
+
+ 2. 次のように開発バージョンのコピーを入手します::
+
+ bzr branch http://bazaar-vcs.org/bzr/bzr.dev
+
+ 3. 作成されたディレクトリ(bzr.dev)をPATHに登録します
+
+上級ユーザーはより早く動かすためにC言語の拡張機能をビルドもしたいことでしょう。
+これは ``make`` と ``pyrex`` とCコンパイラを利用することで実現できます。
+このことに関して手助けが必要であればEメールかIRCを通して連絡をして\
+下さるようお願いします。
+
+
+複数のバージョンを稼働させる
+-----------------------------
+
+Bazaarの複数のバージョンをインストールしてそれらを切り替えることは簡単です。
+これを行うためには、実行したい **bzr** のフルパス名を入力するだけです。
+関連ライブラリは自動的に検出されます。もちろん、パス名を提供しない場合、
+通常のシステムパスで見つかる **bzr** のコマンドが使われます。
+
+この機能は最新バージョンと開発バージョンの両方を走らせたい(テストしたい)場合にとりわけ役立ちます。
diff --git a/doc/ja/user-guide/introducing_bazaar.txt b/doc/ja/user-guide/introducing_bazaar.txt
new file mode 100644
index 0000000..2e4af2b
--- /dev/null
+++ b/doc/ja/user-guide/introducing_bazaar.txt
@@ -0,0 +1,118 @@
+Bazaarの紹介
+=============
+
+Bazaarとは?
+-------------
+
+Bazaarはみんなのコラボレーションを手助けするツールです。
+これは(たとえばソフトウェアのソースコードなどの)ファイルのグループの変化の\
+段階のスナップショットを提供するためにファイルの変更を追跡します。
+この情報を利用することで、Bazaarはあなたの作業と他の人の作業の成果を簡単にマージします。
+
+Bazaarのようなツールはバージョン管理ツール(version control systems: VCS)と呼ばれ\
+長い間ソフトウェアの開発者の間で人気がありました。
+Bazaarは使いやすく、柔軟で簡単にセットアップできるので、ソフトウェアの開発者だけでなく、\
+テクニカルライター、ウェブデザイナー、翻訳者のようなファイルとドキュメントに取り組む\
+人達にも理想的なツールです。
+
+このガイドは、個人で使うのかチームで使うのかに関わらずBazaarのインストールと使い方の手引きをします。
+すでに分散型のバージョン管理システムに慣れ親しんでおりすぐとりかかりたいのであれば、\
+このセクションを流し読みして `さらに学ぶ`_ のセクションに移動するとよいでしょう。
+
+バージョン管理システムの小史
+-----------------------------
+
+バージョン管理ツールは数十年の間に進化してきました。
+簡単に説明すると、ツールは4世代に渡ります:
+
+ 1. ファイルのバージョン管理ツール、たとえばSCCS、RCS
+ 2. ファイルのバージョン管理ツール - 集中型、たとえばCVS
+ 3. ファイルのバージョン管理ツール - 第二世代集中型、たとえばSubversion
+ 4. ファイルのバージョン管理ツール - 分散型、たとえばBazaar
+
+Bazaarの設計と実装は前世代のすべてのツールから学んだことに基づいています。
+とりわけ、Bazaarは集中型と分散型の両方のバージョン管理モデルをサポートするので\
+ツールを変更せずに複数のモデルに対応できます。
+
+集中型 vs 分散型
+-----------------
+
+従来の多くのVCSツールはファイルのツリーに対する履歴(**リポジトリ**, *repository*)
+を提供する中央サーバーが必要です。
+ファイルに対する作業に取り組むために、ユーザーはサーバーに接続してファイルを\
+**チェックアウト** (*checkout*) する必要があります。
+チェックアウトにより、ユーザーが修正できるツリー(**作業ツリー**, *working tree*)ができます。
+これらの変更を記録(**コミット**, *commit*)するためには、集中型のサーバーにアクセスする権限が必要で、\
+コミットをする前に作業内容を最新バージョンとマージしなければなりません。
+このアプローチは集中型モデルとして知られます。
+
+集中型モデルは長期にわたって有用であることを示してきましたが顕著な欠点がいくつかあります。
+先ず第一に、集中型のVCSはバージョン管理機能を利用するためにはサーバーに接続できることを要求します。
+二番目に、集中型のモデルは変更の **スナップショットの記録** のふるまいと変更の **公開**
+のふるまいと密接にリンクさせます。
+これは状況によってはよいこともありますが別の状況では品質にわるい影響を与えることがあります。
+
+分散型のVCSツールは単独の集中型のレポジトリではなく複数のレポジトリをユーザーとチームに持たせます。
+Bazaarでは通常、履歴はバージョン管理されているコードと同じ場所に保存されます。
+これによってユーザーは、オフラインであってもコミットするべきタイミングで変更をコミットできます。
+ネットワークのアクセスは変更を公開するもしくは別の場所の変更にアクセスするときのみ求められます。
+
+実際、分散型VCSツールを賢く使うことでオフライン作業を超えたいくつかの開発者にとっての利点があります。
+
+ * 開発者が実験用のブランチを作るのが簡単になります
+ * 仲間とのアドホックなコラボレーションが簡単になります
+ * ルーチンタスクの時間が減ります - より創造的な活動に時間を割けます
+ * "feature-wide" コミットの利用を通してリリース管理の柔軟性が増します
+ * トランクの質と安定性を高い水準で維持でき、それによって作業者のストレスが少なくなります
+ * オープンなコミュニティにおいて:
+
+ * コア開発者ではない人が作成と変更の維持をしやすくなります
+ * コア開発者が外部の開発者と共同作業をしてコアのチームに組み込むことが楽になります
+
+ * 会社において、分散されたチームや外部のチームと連携するのが簡単になります
+
+分散型VCSツールの集中型より優れた点の詳細な一覧に関しては、 http://wiki.bazaar.canonical.com/BzrWhy
+を参照してください。
+
+
+Bazaarの主要な機能
+-------------------
+
+Bazaarは現存する唯一のVCSツールではありませんが、多くのチームとコミュニティにとって\
+よい選択肢になる優れた機能をいくつか持ちます。
+別のVCSツールとの比較の要約はBazaarのWiki、 http://wiki.bazaar.canonical.com で見つかります。
+
+多くの機能の中で、とりわけ強調するものがあります:
+BazaarはPythonで書かれた完全にフリーなソフトウェアです。
+結果として、改善に貢献することは簡単です。
+手を貸して頂けるのであれば、 http://wiki.bazaar.canonical.com/BzrSupport を参照して頂くようお願いします。
+
+
+さらに学ぶ
+-----------
+
+このマニュアルではBazaarの簡単な紹介と効果的な使い方を提供します。
+すべてのユーザーは、少なくとも次の点について書かれたこの章の残りを読むことが推奨されます:
+
+ * ユーザーが知る必要のある中心的な概念を説明します
+ * Bazaarを利用した人気のある方法をいくつか紹介します
+
+2-6章ではさまざまなタスクを実現するためにBazaarを使う方法を詳しく説明します。
+Bazaarを使い始めた後で最初から最後まで読むことをほとんどの方にお勧めします。
+7章とそれ以降はコアの機能を理解した上でBazaarを利用する際に手助けになる追加情報を提供します。
+この教材は必要なときに任意の順番で読むことができます。
+
+すでに他のバージョン管理ツールに慣れ親しんでいるのであれば、次のドキュメントを読んですぐに始めるとよいでしょう:
+
+ * 5分でBazaar_ - ミニチュートリアル
+ * Bazaarクィックスタートカード_ - よく使われるコマンドを1ページにまとめた要約。
+
+加えて、オンラインのヘルプと `Bazaarユーザーリファレンス`_
+は利用可能なコマンドとオプションのすべての詳細を提供します。
+
+.. _5分でBazaar: ../mini-tutorial/index.html
+.. _Bazaarクィックスタートカード: ../quick-reference/index.html
+.. _Bazaarユーザーリファレンス: ../user-reference/index.html
+
+このマニュアルがお役に立てることを願っております。Bazaarの残りのドキュメントの改善を提案したいのであれば、
+メーリングリスト(bazaar@lists.canonical.com)に連絡して頂けるようお願いします。
diff --git a/doc/ja/user-guide/licence.txt b/doc/ja/user-guide/licence.txt
new file mode 100644
index 0000000..09af80e
--- /dev/null
+++ b/doc/ja/user-guide/licence.txt
@@ -0,0 +1,7 @@
+Licence
+===============
+
+Copyright 2009-2011 Canonical Ltd. Bazaar is free software, and you
+may use, modify and redistribute both Bazaar and this document under
+the terms of the GNU General Public License version 2 or later. See
+<http://www.gnu.org/licenses/>.
diff --git a/doc/ja/user-guide/merging_changes.txt b/doc/ja/user-guide/merging_changes.txt
new file mode 100644
index 0000000..7f0664e
--- /dev/null
+++ b/doc/ja/user-guide/merging_changes.txt
@@ -0,0 +1,93 @@
+変更をマージする
+=================
+
+並行開発
+---------
+
+誰かがプロジェクトの独自ブランチを持ったら、 並行して変更を行い、\
+オリジナルのブランチを続ける開発にコミットできます。
+まもなくですが、開発の独立したラインを結合することが必要にあります。
+このプロセスは *マージ (merging)* として知られます。
+
+mergeコマンド
+-------------
+
+別のブランチから変更を受け入れるためには、 ``merge`` コマンドを使います。
+構文は次のとおりです::
+
+ bzr merge [URL]
+
+URLが渡されない場合、オリジナルのものから由来する初期のブランチがデフォルト\
+として使われます。
+たとえば、BillがMaryの作業内容からブランチを作る場合、
+下記のようにコマンドを入力すれば彼女の次の変更をマージできます::
+
+ bzr merge
+
+一方で、MaryはBillのブランチで行われた作業内容を彼女のブランチにマージ\
+したいかもしれません。
+この場合、彼女は最初に明示的にURLを渡す必要があります::
+
+ bzr merge bzr+ssh://mary@bill-laptop/cool-repo/cool-trunk
+
+マージブランチがまだ設定されていなければ、これによってデフォルトの\
+マージブランチが設定されます。
+設定した後でデフォルトを変更するためには、 ``--remember`` オプション\
+を使います。
+
+マージの動作方法は?
+--------------------
+
+マージのためのいくつかのアルゴリズムがあります。
+Bazaarのデフォルトのアルゴリズムは次のように動作する
+*3方向マージ (3-way merging)* の一種です。
+Aが祖先でBとCの2つがブランチであると仮定すると、次のテーブルは使われるルールを\
+提示します。
+
+ === === === ====== =================
+ A B C 結果 コメント
+ === === === ====== =================
+ x x x x unchanged
+ x x y y line from C
+ x y x y line from B
+ x y z ? conflict
+ === === === ====== =================
+
+マージの中には人間の手助けによってのみ完了するものがあることに留意してください。
+これらを解決する方法の詳細は `衝突を解消する <resolving_conflicts.html>`_ を参照してください。
+
+マージを記録する
+-----------------
+
+衝突が解決した後で、マージをコミットする必要があります。例です::
+
+ bzr commit -m "Merged Mary's changes"
+
+衝突が無くても、明確なコミットがまだ必要です。
+他のツールとは異なり、これはBazaarの機能と考えられています。
+クリーンなマージは必ずしもよいマージとは限らないので、個別の明確なステップ\
+としてコミットすることで、すべてがよい状態にあることを検証するための最初の\
+テストスィートを実行できます。
+
+問題が見つかったら、マージをコミットする前にそれらを訂正する\
+もしくは ``revert`` を使用してマージを廃棄すべきです。
+
+マージの追跡
+------------
+
+Bazaarの機能の中で最も重要な機能の1つは、分散型で高品質の\
+*マージトラッキング* です。
+言い換えると、Bazaarは何がすでにマージされていることを覚えており、\
+マージのための最良の祖先を賢く選ぶためにその情報を使い、\
+衝突の回数と規模を最小にします。
+
+あなたが他の多くのVCSツールの難民であるなら、
+*何が何でもマージは避けさせてください* という習慣から抜け出すのは\
+本当に難しいかもしれません。
+Bazaarによっていつでも安全に他の人とのマージを行うことができます。
+peer-to-peerの方法でうまくゆくときに、高い品質を保つために、
+"統合のたまり場"として集中型のブランチを使うことも避けられます。
+コラボレーションしている変更を本当に広く共有する準備ができたら、\
+変更を中心のブランチにマージしてコミットする機会です。
+
+このようにマージ機能がうまくゆけば開発者の共同作業の方法を変えることができます。
diff --git a/doc/ja/user-guide/organizing_branches.txt b/doc/ja/user-guide/organizing_branches.txt
new file mode 100644
index 0000000..0804b2f
--- /dev/null
+++ b/doc/ja/user-guide/organizing_branches.txt
@@ -0,0 +1,95 @@
+ブランチを編成する
+===================
+
+ミラーブランチ
+----------------
+
+開発をするために分散型のワークフローを利用する際の主要な違いは\
+メインのローカルブランチは変更を行う場所ではないことです。
+代わりに、中心ブランチのそのままのコピーとして保存されます。
+すなわち、これは *ミラーブランチ* です。
+
+ミラーブランチを作るためには、共用リポジトリ(まだなければ)を作り\
+ミラーを作るために ``branch`` コマンド(もしくは ``checkout``)を使います。
+例です::
+
+ bzr init-repo PROJECT
+ cd PROJECT
+ bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+タスクのブランチ
+-----------------
+
+それぞれの新しい機能もしくは修正は独自のブランチの中で開発されます。
+これらのブランチは *機能ブランチ* もしくは *タスクブランチ* として言及されます -
+用語はお互いに置き換えて使うことができます。
+
+タスクブランチを作るためには、ミラーブランチに対して ``branch`` コマンドを使います。
+例です::
+
+ bzr branch trunk fix-123
+ cd fix-123
+ (hack, hack, hack)
+
+この方法には数多くの利点があります:
+
+ 1. 並行して複数の変更に取り組むことができます
+ 2. 変更の間の交換が減ります
+ 3. 複数の人々は準備ができるまでpeer-to-peerモードでブランチに取り組むことができます
+
+とりわけ、変更が他のものより料理するのに時間がかかるのであれば、レビューを求めたり、
+フィードバックを適用することができます。
+中心ブランチにマージする前に個別のブランチで十分な品質の作業を完了させることで、
+中心ブランチの品質と安定性は以前よりも高い水準を維持します。
+
+ミラーブランチをリフレッシュする
+---------------------------------
+
+これを行うためには ``pull`` コマンドを使います::
+
+ cd trunk
+ bzr pull
+
+最新のトランクを機能ブランチにマージする
+-----------------------------------------
+
+これを行うためには ``merge`` コマンドを使います::
+
+ cd fix-123
+ bzr merge
+ (resolve any conflicts)
+ bzr commit -m "merged trunk"
+
+機能をトランクにマージする
+---------------------------
+
+異なる分散型のワークフローの方針は変わります、
+すべての開発者がメイントランクにコミットする権限を持つ最もシンプルな\
+事例は下記のとおりです。
+
+ミラーがチェックアウトなら::
+
+ cd trunk
+ bzr update
+ bzr merge ../fix-123
+ (resolve any conflicts)
+ bzr commit -m "Fixed bug #123"
+
+ミラーがブランチの場合::
+
+ cd trunk
+ bzr pull
+ bzr merge ../fix-123
+ (resolve any conflicts)
+ bzr commit -m "Fixed bug #123"
+ bzr push
+
+タスクブランチをバックアップする
+--------------------------------
+
+集中型ワークフローの副作用の1つは変更がITオペレーションの一部として\
+バックアップされる中心位置にしょっちゅうコミットされることです。
+タスクブランチを開発するとき、作業内容を中心位置に公開することは\
+バックアップになるのでよい考えです(しかし共用位置であることは必須ではありません)。
+この目的のためだけにローカルのタスクブランチをバックアップサーバー上で\
+確立されたリモートブランチにバインドするとよいかもしれません。
diff --git a/doc/ja/user-guide/organizing_your_workspace.txt b/doc/ja/user-guide/organizing_your_workspace.txt
new file mode 100644
index 0000000..6135326
--- /dev/null
+++ b/doc/ja/user-guide/organizing_your_workspace.txt
@@ -0,0 +1,177 @@
+.. _organizing-your-workspace:
+
+作業スペースを構成する
+=========================
+
+.. _common-workspace-layouts:
+
+一般的なレイアウト
+---------------------
+
+Bazaarのユーザーがプロジェクトのための作業スペースを構成するベストな方法は、\
+次のような要素に依存します:
+
+* ユーザーの役割: プロジェクトオーナー vs コア開発者 vs カジュアルな貢献者
+
+* ワークフロー: プロジェクトが推奨/強制している、貢献のためのワークフロー
+
+* サイズ: 大きいプロジェクトは小さいプロジェクトよりもリソースを要求します。
+
+少なくとも4つの一般的なワークスペースの構成方法があります。
+
+* lightweight checkout
+* standalone tree
+* feature branches
+* switchable sandbox.
+
+各レイアウトの簡単な説明を以下に記します。
+
+
+軽量チェックアウト
+--------------------
+
+このレイアウトでは、作業ツリーはローカルですがブランチはリモートにあります。
+これはCVSやSVNで一般的に利用されるレイアウトで、シンプルで簡単に理解できます。
+
+セットアップするには::
+
+ bzr checkout --lightweight URL project
+ cd project
+
+作業するには::
+
+ (make changes)
+ bzr commit
+ (make changes)
+ bzr commit
+
+各コミットが暗黙的に変更を同じブランチを利用している他の人に公開していることに\
+注意してください。ただし、コミットが成功するには作業ツリーがリモートのブランチの\
+最新の状態になっている必要があります。最新のコードを取得してマージするには、::
+
+ bzr update
+
+
+スタンドアロンツリー
+----------------------
+
+このレイアウトでは、作業ツリーとブランチは一つの場所にあります。
+共有リポジトリが上位のディレクトリに無い限り、リポジトリも同じ場所に\
+格納されます。これはBazaarのデフォルトレイアウトで、小規模から中規模の\
+大きさのプロジェクトに適しています。
+
+セットアップ::
+
+ bzr branch URL project
+ cd project
+
+作業::
+
+ (make changes)
+ bzr commit
+ (make changes)
+ bzr commit
+
+変更を中央の場所に公開する::
+
+ bzr push [URL]
+
+pushするURLは最初の一回だけ要求されます。
+
+もし中央の場所が、pushするまでの間に他のユーザーからの変更を受け取っていた\
+場合、pushする前にそれらの変更をローカルブランチにmergeする必要があります::
+
+ bzr merge
+ (resolve conflicts)
+ bzr commit
+
+代替手段として、チェックアウトを使うこともできます。ブランチと同じように\
+チェックアウトも履歴全体をローカルにコピーしますが、ローカルブランチが\
+リモートの場所に束縛されているので、両方のブランチに一度にコミットされます。
+
+注意: チェックアウトはローカルコミット+pushに比べてスマートです。
+チェックアウトはまずリモートにコミットして、それが成功したときにだけ\
+ローカルにもコミットします。
+
+.. _feature-branches:
+
+機能ブランチ
+--------------
+
+このレイアウトでは、いくつかのブランチとツリーがあって、一般的にリポジトリを共有します。
+一つのブランチは "trunk" のミラーを保存していて、それ以外の作業単位(例:バグ修正や
+機能追加)にはそれぞれの "機能ブランチ" を作ります。
+このレイアウトはほとんどのプロジェクト、特に中規模のものにとって理想的です。
+
+セットアップ::
+
+ bzr init-repo project
+ cd project
+ bzr branch URL trunk
+
+機能ブランチを開始する::
+
+ bzr branch trunk featureX
+ cd featureX
+
+作業する::
+
+ (make changes)
+ bzr commit
+ (make changes)
+ bzr commit
+
+変更をメーリングリストに公開してレビュー&承認してもらう::
+
+ bzr send
+
+変更を公開ブランチで公開する(たとえばLaunchpad上でmerge要求を出すために)::
+
+ bzr push [URL]
+
+変化形として、trunkをチェックアウトとして作ることもできます。
+もしtrunkへのコミット権限を持っているのであれば、trunkへマージして\
+コミットするとその変更は暗黙的に公開されます。
+他には、trunkのURLが読み込み専用だった場合(例: HTTP アドレス)、チェックアウトを\
+利用することはローカルのtrunkミラーに間違えて変更を登録してしまうことを\
+防止します。これはプロジェクトがPQMなどのゲートキーパー型のワークフロー\
+を利用していたときに有用です。
+
+
+.. _local-sandbox:
+
+ローカルのsandbox
+------------------
+
+このレイアウトは機能ブランチのレイアウトとほぼ同じですが、機能ブランチが\
+それぞれ作業ツリーを持つ代わりに一つの作業ツリーを共用する点が違います。
+これはgitのデフォルトレイアウトに似ていて、大きなツリー(10000ファイル以上\
+とか)を持つプロジェクトや、ビルドによる加工物(.oや.classファイルといった)\
+を大量に作るプロジェクトに適しています。
+
+セットアップ::
+
+ bzr init-repo --no-trees project
+ cd project
+ bzr branch URL trunk
+ bzr checkout --lightweight trunk sandbox
+ cd sandbox
+
+これでsandboxで作業を開始できますが、sandboxがtrunkを参照したままコミット\
+してしまうと、(trunkがcheckoutで無い限り)trunkが元のtrunkのミラーでは\
+なくなってしまいます。
+なので、まず機能branchを作ってsandboxをそちらに紐づけましょう::
+
+ bzr branch ../trunk ../featureX
+ bzr switch ../featureX
+
+この後の、変更を行ったりその変更を公開して適用してもらうまでの\
+プロセスは機能ブランチレイアウトの時と同じです。
+
+
+進んだレイアウト
+----------------
+
+お望みとあれば、あなたのお好みの構成に合わせてレイアウトを決めることができます。
+例やアイデアについては `共有リポジトリのレイアウト <shared_repository_layouts.html>`_
+を参照してください。
diff --git a/doc/ja/user-guide/part2_intro.txt b/doc/ja/user-guide/part2_intro.txt
new file mode 100644
index 0000000..e5a73c9
--- /dev/null
+++ b/doc/ja/user-guide/part2_intro.txt
@@ -0,0 +1,11 @@
+これからの長い旅
+=================
+
+前の章でBazaarがあなた自身と他の人との共同作業を生産的にすることを手助け\
+してくれる方法について確固として理解して頂けることを筆者達は願っております。
+初めてBazaarを学んでいるのであれば、一度習得したら、このマニュアルに戻るために\
+すでにカバーされた手順を試すとよいかもしれません。
+
+残りの章ではBazaarをより適切に使うためのさまざまなトピックをカバーしています。
+明言されない限り、この章と残りの章はそれぞれ独立しているので好きな順序で
+読むことができます。
diff --git a/doc/ja/user-guide/partner_intro.txt b/doc/ja/user-guide/partner_intro.txt
new file mode 100644
index 0000000..68f4f51
--- /dev/null
+++ b/doc/ja/user-guide/partner_intro.txt
@@ -0,0 +1,33 @@
+他の人と連携する
+=================
+
+Peer-to-peerをうまくやる
+-------------------------
+
+多くの場合、1人よりも2人で考える方がベターです。
+1人でプロジェクトを始め、誰かがあなたを手伝いたい、もしくはあなたが別の人に助けを求めたいことがあります。
+ペアプログラマとしてタスクを割り当てられたより大きなチームのメンバーであることでしょう。
+どちらにしても、効率よく共同作業を行うために、2人の人間がプロセス、ガイドラインとツールセットの一式に同意する必要があります。
+
+誰かに電話で直接呼び出すことが許可されていなくて、彼らに話しかける唯一の方法は最初に電話会議を予約することである場合を想像してください。
+集中型のVCSのリポジトリを通してのみコードを共有する企業とコミュニティは毎日\
+そのような拘束に耐えています。
+中央管理がうまくいくときもあれば、peer-to-peerがうまくいくときもあります。
+Bazaarはどちらの場合でも手助けになるように設計されました。
+
+パートナーのワークフロー
+-------------------------
+
+これは唯一の方法ではありませんが、下記の *パートナーのワークフロー* はBazaarを利用してペアで共同作業をしたい人々のためのよいスタート地点です。
+
+.. image:: images/workflows_peer.png
+
+以前の章でカバーしたタスクに加えて、この章では2つの必要不可欠なコラボレーション活動を紹介します:
+
+ * ブランチのコピーを手に入れる
+ * 複数のブランチの間の変更をマージする
+
+コードベースに取り組むだけのときでも、たとえば異なるリリースのために\
+複数のブランチを手元に置き必要に応じてそれらの変更をマージすることは\
+とても実用的です。
+あなたの "パートナー" が本当にあなた自身かもしれませんから。
diff --git a/doc/ja/user-guide/plugins.txt b/doc/ja/user-guide/plugins.txt
new file mode 100644
index 0000000..0536281
--- /dev/null
+++ b/doc/ja/user-guide/plugins.txt
@@ -0,0 +1,97 @@
+プラグインを利用する
+=====================
+
+.. Information on how to use plugins in Bazaar.
+
+プラグインとは?
+-----------------
+
+プラグインは主にサードパーティによって作られたBazaarのための外部コンポーネントです。
+プラグインは新しい機能を追加することでBazaarを補強する能力があります。
+プラグインは現在の機能を置き換えることでBazaarのふるまいを変更することもできます。
+プラグインのサンプルのアプリケーションは次のとおりです:
+
+* コマンドをオーバーライドする
+* 新しいコマンドを追加する
+* 追加のネットワーク転送機能を提供する
+* ログの出力をカスタマイズする
+
+プラグインを通してできるカスタマイズの可能性は際限がありません。
+実際、開発者が新しい機能を公式のコードベースに含める前にテストするための方法としてプラグインは機能します。
+プラグインは機能の引退時でも同様に役立ちます。たとえば廃止されたファイルのフォーマットがある日Bazaarのコアから除外されるかもしれませんが\
+代わりにプラグインとして利用できます。
+
+プラグインはユーザーにとって、外部の開発者にとっても、Bazaar自身にもよいものです。
+
+プラグインが見つかる場所
+-------------------------
+
+http://wiki.bazaar.canonical.com/BzrPlugins ページで
+プラグインのリストが見つかります。
+
+プラグインをインストールする方法
+---------------------------------
+
+プラグインのインストール作業はとても簡単です! まだ作られていなければ、
+Bazaarの設定ディレクトリの元で ``plugins`` ディレクトリを作ります。
+Unix の場合は ``~/.bazaar/`` でWindowsの場合は
+``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\`` です。
+このディレクトリの範囲内では(下記では$BZR_HOMEとして言及される) それぞれのプラグインは独自のサブディレクトリに設置されます。
+
+プラグインはとりわけBazaarのブランチとよく連携します。
+たとえば、 GNU/Linux のメインのユーザーアカウント用に bzrtools
+プラグインをインストールするためには、次のコマンドを実行します::
+
+ bzr branch http://panoramicfeedback.com/opensource/bzr/bzrtools
+ ~/.bazaar/plugins/bzrtools
+
+プラグインをインストールするディレクトリの名前はPythonの有効な識別子でなければなりません。
+このことはディレクトリは特定の文字だけを含まなければならないことを意味します。とりわけハイフン (``-``) を含んではなりません。
+``bzr-gtk`` を ``$BZR_HOME/plugins/bzr-gtk`` にインストールするよりも、 ``$BZR_HOME/plugins/gtk`` にインストールします。
+
+プラグインの代替用の場所
+-------------------------
+
+必要なパーミッションがあれば、プラグインをシステム全体のベースに
+インストールすることもできます。
+
+環境変数 ``BZR_PLUGIN_PATH`` をプラグインが含まれるディレクトリに
+設定することで個人のプラグインの場所を上書きできます。
+(詳細な解説は
+`ユーザーリファレンス <../user-reference/configuration-help.html#bzr-plugin-path>`_
+を参照してください。)
+
+
+インストールされたプラグインの一覧を表示する
+---------------------------------------------
+
+これを行うためには、次のようにpluginsコマンドを使います::
+
+ bzr plugins
+
+それぞれのプラグインの名前、場所とバージョンが表示されます。
+
+プラグインによって追加された新しいコマンドは ``bzr help commands`` を実行することで見ることができます。
+プラグインによって提供されたコマンドはブラケットの中のプラグインの名前に従って表示されます。
+
+人気のあるプラグイン
+--------------------
+
+次の表は人気のあるプラグインのサンプルです。
+
+ ================ ================= ==================================
+ カテゴリ 名前 説明
+ ================ ================= ==================================
+ GUI QBzr QtベースのGUIツール
+ GUI bzr-gtk GTKベースのGUIツール
+ GUI bzr-eclipse Eclipseとの統合
+ General bzrtools その他。shelfを含めた機能の強化
+ General difftools 外部の差分ツールヘルパー
+ General extmerge 外部のマージツールヘルパー
+ Integration bzr-svn Subversionをリポジトリとして利用する
+ Migration cvsps CVSパッチセットを移行させる
+ ================ ================= ==================================
+
+あなた独自のプラグインを書きたい場合、難しいことではありません。
+始めるためには付録の `プラグインを書く <writing_a_plugin.html>`_
+の項目をご覧ください。
diff --git a/doc/ja/user-guide/publishing_a_branch.txt b/doc/ja/user-guide/publishing_a_branch.txt
new file mode 100644
index 0000000..2a4c632
--- /dev/null
+++ b/doc/ja/user-guide/publishing_a_branch.txt
@@ -0,0 +1,69 @@
+.. _publishing_a_branch:
+
+ブランチを公開する
+===================
+
+集中型リポジトリをセットアップする
+-------------------------------------
+
+集中型のワークフローはコンピュータ上のブランチを中心型のブランチ\
+として指名することで使うことができます。
+実際大抵のチームは集中型のブランチをホストするために専用サーバーを\
+持ちます。
+
+共用リポジトリをローカルで使うことが最良の習慣であるように、\
+中心型のブランチを共用リポジトリを設置することもお勧めです。
+通常は、中心型の共用ブランチはファイルの作業コピーではなく\
+履歴のみを保存することに注意してください。
+なので、そのような共有リポジトリを作るときには通常 ``no-trees``
+オプションを使います::
+
+ bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/PROJECT
+
+この手順をcvsrootもしくはSubversionのリポジトリのセットアップとして\
+似たようなものとして考えることができます。
+しかしながら、Bazaarはリポジトリ内のブランチの編成方法をより柔軟にします。
+ガイドラインと例に関しては付録の
+`共用レポジトリのレイアウト <shared_repository_layouts.html>`_ を参照してください。
+
+
+集中型ブランチを始める
+-------------------------
+
+集中型ブランチに初期の内容を投入する方法は2つあります:
+
+ 1. ローカルのブランチを作り中央にプッシュする
+ 2. 空の中央ブランチを作り内容をコミットする
+
+最初のやり方の例です::
+
+ bzr init-repo PROJECT (ローカルリポジトリを準備する)
+ bzr init PROJECT/trunk
+ cd PROJECT/trunk
+ (開発ファイルをコピーする)
+ cp -ar ~/PROJECT . (OS固有のツールを使用してファイルをコピーする)
+ bzr add (リポジトリを投入する; バージョン管理を始める)
+ bzr commit -m "Initial import"
+ (中心リポジトリに公開する)
+ bzr push bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+2番目のやり方の例です::
+
+ bzr init-repo PROJECT (ローカルリポジトリを準備する)
+ cd PROJECT
+ bzr init bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+ bzr checkout bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+ cd trunk
+ cp -ar ~/PROJECT . (OS固有のツールを使用してファイルをコピーする)
+ bzr add (リポジトリを投入する; バージョン管理を始める)
+ bzr commit -m "Initial import"
+ (中心リポジトリに公開する)
+
+``checkout`` コミットを使って作られた作業ツリー内部でコミットすると\
+ローカルと同様に内容は暗黙の内に中心位置にコミットされることに注意してください。
+``checkout`` の代わりに ``branch`` コマンドを使ったので、\
+内容はローカルにのみコミットされます。
+
+このように中心位置に密接に連動した作業ツリーは *チェックアウト(checkouts)*
+と呼ばれます。
+この章の残りでは数多くの機能を詳しく説明します。
diff --git a/doc/ja/user-guide/recording_changes.txt b/doc/ja/user-guide/recording_changes.txt
new file mode 100644
index 0000000..33974c5
--- /dev/null
+++ b/doc/ja/user-guide/recording_changes.txt
@@ -0,0 +1,76 @@
+変更を記録する
+===============
+
+bzr commit
+----------
+
+作業ツリーの状態が満足のゆくものであるとき、これをブランチに **コミット** できます。
+そしてその状態のスナップショットを保持する新しいリビジョンが作られます。
+
+**commit** コマンドはリビジョンの変更を記述するメッセージをとります。
+コミットはあなたのユーザーID、現在の時間とタイムゾーン、一覧表とツリーの内容も記録します。
+コミットメッセージは ``-m`` もしくは ``--message`` オプションによって指定されます。
+複数行のコミットメッセージを入力できます;
+大抵のシェルでは行の終わりで引用符を開いたままにするだけで入力できます。
+
+::
+
+ % bzr commit -m "added my first file"
+
+ファイルからメッセージを得るために ``-F`` オプションを使うことができます。
+中には、作業している間にコミットメッセージ用のノートを作り、自分が何を行い何を発言したのか
+確認するために差分をレビューしたい人がいます。
+(このファイルは一休みしてから作業を取り出すのにも役立ちます)
+
+エディタからのメッセージ
+-------------------------
+
+``-m`` もしくは ``-F`` オプションを使わないのであれば、
+bzrはメッセージを入力するためにエディタを開きます。
+起動させるエディタは ``$VISUAL`` もしくは ``$EDITOR`` 環境変数によって制御され、
+``~/.bazaar/bazaar.conf`` の中の ``editor`` 設定によって上書きできます;
+``$BZR_EDITOR`` は上記で言及したエディタのオプションを上書きします。
+変更なしでエディタを閉じると、コミットはキャンセルされます。
+
+エディタの中で開かれるファイルは境界線を含みます。
+この行の下のファイルの部分は情報用のみのために含まれ、コミットメッセージには\
+含まれません。
+セパレータの下側はコミットで変更されるファイルの一覧が表示されます。
+上記の行の上側でメッセージを書き、ファイルを保存して閉じます。
+
+編集メッセージとしてコミットする差分を見たければ ``--show-diff`` オプションを使うことができます。
+これはエディタが開くときにエディタの差分を含みます。セパレータの下とファイルに関する情報はコミットされます。
+これは書いたメッセージを読むことができることを意味しますが、
+差分自身は終了したときにコミットメッセージに表示されません。
+一部をメッセージに含めたいのであれば、それらをセパレータの上側にコピー&ペーストできます。
+
+選択可能なコミット
+------------------
+
+コミットのコマンドラインでファイルもしくはディレクトリの名前を渡すと
+それらのファイルへの変更のみがコミットされます。たとえば::
+
+ % bzr commit -m "documentation fix" commit.py
+
+デフォルトではサブディレクトリから実行されたとしても
+bzrは常にツリーへのすべての変更をコミットします。
+現在のディレクトリのみからコミットするには、ドットを引数として使います::
+
+ % bzr commit .
+
+変更に署名をつける
+-------------------
+
+たとえば誰かのパッチを適用するときなど、コミットしようとしている変更があなたのものでないなら、 ``--author`` という commit のオプションを使って変更に署名をつけられます。 ::
+
+ % bzr commit --author "Jane Rey <jrey@example.com>"
+
+ここで指定された人はそのリビジョンの "author" として記録され、\
+あなたはそのリビジョンの "committer" として記録されます。
+
+もしリビジョンの変更がペアプログラミングなどにより複数の人に作られたもの\
+ならば、 ``--author`` を複数回指定して記録することができます。 ::
+
+ % bzr commit --author "Jane Rey <jrey@example.com>" \
+ --author "John Doe <jdoe@example.com>"
+
diff --git a/doc/ja/user-guide/releasing_a_project.txt b/doc/ja/user-guide/releasing_a_project.txt
new file mode 100644
index 0000000..c2f6faf
--- /dev/null
+++ b/doc/ja/user-guide/releasing_a_project.txt
@@ -0,0 +1,43 @@
+プロジェクトをリリースする
+==========================
+
+リリースをパッケージ化する
+--------------------------
+
+``export`` コマンドはリリースのパッケージを作成するために使われます。
+すなわち、ブランチの中のファイルとディレクトリをコピーしてそれらを真新しいディレクトリもしくはアーカイブファイルのパッケージを作成します。
+たとえば、このコマンドは最後にコミットされたバージョンを ``tar.gz`` アーカイブファイルにパッケージ化します::
+
+ bzr export ../releases/my-stuff-1.5.tar.gz
+
+``export`` コマンドは下記に示されるアーカイブのタイプを作るためにアーカイブファイルの接尾辞を使います。
+
+ ========================== ===================
+ サポートされるフォーマット 拡張子で自動検出
+ ========================== ===================
+ dir (none)
+ tar .tar
+ tbz2 .tar.bz2, .tbz2
+ tgz .tar.gz, .tgz
+ zip .zip
+ ========================== ===================
+
+最新のリビジョン以外のリビジョンをパッケージにすることを望むのであれば、 ``-r`` オプションを使います。
+アーカイブ内部のrootディレクトリを調整したいのであれば、 ``--root``
+オプションを使います。
+``export`` によってサポートされるオプションの詳細については
+オンラインヘルプもしくはユーザーリファレンスを参照してください。
+
+リリースをタギングする
+-----------------------
+
+リリースのパッケージを作成するために使われたバージョンを覚えるよりも、
+``tag`` コマンドを使ってバージョンのためのシンボルを定義する方が便利です::
+
+ bzr tag version-1-5
+
+リビジョンの識別子が必要なときはいつでもそのタグを使うことができます::
+
+ bzr diff -r tag:version-1-5
+
+ブランチの中で定義したタグの一覧を見たい場合、 ``tags`` コマンドを使います。
diff --git a/doc/ja/user-guide/resolving_conflicts.txt b/doc/ja/user-guide/resolving_conflicts.txt
new file mode 100644
index 0000000..8a29bcc
--- /dev/null
+++ b/doc/ja/user-guide/resolving_conflicts.txt
@@ -0,0 +1,75 @@
+衝突の解消
+===========
+
+ワークフロー
+-------------
+
+マージプロセスの間にそれぞれの衝突を解消することを強制する他のいくつかのツール\
+とは異なり、Bazaarはできる限りマージしてから衝突を報告します。
+これによって衝突の解消をより扱いやすくします。
+解消すべき方法を決めることを手助けするためにポストマージツリー全体の内容が\
+利用可能だからです。
+それぞれの解消もしくはグループがよい状態であることを確認するためにテストを\
+いくつか選んで実行することもよいでしょう。
+
+衝突の一覧を表示する
+---------------------
+
+``merge`` コマンドで報告されるのと同様に、\
+突出した衝突の一覧は ``conflicts`` コマンドを使用することでいつでも表示されます。
+これは ``status`` コマンドから出力の一部として含めることも可能です。
+
+衝突を解消する
+--------------
+
+衝突に遭遇したら、 ``merge`` コマンドは解決されていない領域を表示する\
+埋め込みマーカーをそれぞれのファイルに追加します。
+1つの衝突を持つそれぞれのファイルに対して3つのファイルも作ります:
+
+ * foo.BASE
+ * foo.THIS
+ * foo.OTHER
+
+``foo`` は衝突したファイルの名前です。
+多くの場合、問題になっているそれぞれのファイルを手作業で編集し、\
+関連領域を修正し衝突マーカーを除去することで衝突を解消できます。
+
+衝突の中のすべてのファイルを修正し、マーカーを削除した後で、
+``resolve`` コマンドを使用してBazaarにそれらを解決したものとしてマークするように頼みます::
+
+ bzr resolve
+
+代わりに、それぞれのファイルを修正した後で、これを解消したものとしてマークできます::
+
+ bzr resolve foo
+
+``resolve`` コマンドは作業ツリーからBASE, THIS, OTHERファイルをクリーンナップします。
+
+remergeコマンドを使う
+---------------------
+
+いくつかの場合、任意のファイルに対して異なるマージアルゴリズムを試したいことがあります。
+これを行うためには、ファイルを次のように指定して ``remerge`` コマンドを使います::
+
+ bzr remerge --weave foo
+
+``foo`` はファイルで ``weave`` オプションは利用可能なマージアルゴリズムです。
+いわゆる ``criss-cross`` (十字遺伝)マージが検出されたときに、
+たとえば、2つのブランチが同じものをマージしてからお互いをマージするときに、\
+このアルゴリズムはとりわけ便利です。
+詳細については ``criss-cross`` と ``remerge`` のオンラインヘルプを参照してください。
+
+衝突を解消するために外部ツールを利用する
+-----------------------------------------
+
+衝突を解消するためにGUIツールを利用したいのであれば、
+*extmerge* プラグインをインストールしてください。次のようにインストールできます::
+
+ bzr extmerge foo
+
+``foo`` は衝突したファイルです。
+解消するファイルの一覧を提供するよりも、すべての衝突ファイルを暗黙の内に指定するために ``--all`` オプションを利用できます。
+
+``extmerge`` コマンドは ``bazaar.conf`` ファイルの中の ``external_merge`` 設定によって指定されるツールを使います。
+設定されていなければ、 ``kdiff3`` もしくは ``opendiff`` のような人気のあるマージツールが設定されます。
+後者はOS XのFileMergeのコマンドラインインターフェイスです。
diff --git a/doc/ja/user-guide/reusing_a_checkout.txt b/doc/ja/user-guide/reusing_a_checkout.txt
new file mode 100644
index 0000000..e59798e
--- /dev/null
+++ b/doc/ja/user-guide/reusing_a_checkout.txt
@@ -0,0 +1,83 @@
+チェックアウトを再利用する
+===========================
+
+動機
+-----
+
+時々、複数のブランチに取り組むために単独のチェックアウトを\
+サンドボックスとして持つことは便利です。
+挙げられる理由のいくつかは次の内容を含みます:
+
+ * 作業ツリーが大きいときディスクスペースを節約する
+ * 固定された位置で開発する
+
+多くの場合、作業ツリーのディスクの利用量は ``.bzr`` ディレクトリよりも
+大きくなります。
+複数のブランチに取り組みたいが、それぞれの作業ツリーすべてのオーバーヘッドを\
+許容できない場合、複数のブランチをまたがってチェックアウトを再利用することが\
+うまくゆく方法です。
+
+他の機会において、サンドボックスの位置は数多くの開発とテストツールに設定されます。
+繰り返しますが、複数のブランチをまたがったチェックアウトの再利用は役に立ちます。
+
+
+ブランチが結びつけられた場所を変更する
+---------------------------------------
+
+チェックアウトが結びつけられている場所を変更するためには、次の手順に従います:
+
+ 1. 作業内容が失われないようにローカルの変更が中央ブランチにコミット
+ されたことを確認します
+
+ 2. 取り組みたい新しいリモートブランチのURLを渡して ``bind`` コマンドを使います
+
+ 3. ``revert`` コマンドの後に続いて ``update`` コマンドを使用して望むブランチの
+ コピーをチェックアウトします
+
+新しいブランチに bind して update するだけだと、コミットしたもの、していないもの\
+両方のローカルの変更がマージされることに注意してください。
+``revert`` か ``commit`` を使って、それらを維持するか破棄するかを決めなければ\
+いけません。
+
+bind+update レシピの代わりは ``switch`` コマンドを使うことです。これは基本的に、\
+ツリーの中のコミットされていない変更がマージされること以外は、既存のブランチを\
+除去して新しい位置で ``checkout`` を再び実行することと同じです。
+
+注: 場合によってバインドされた異なるブランチの適切なキャッシュをチェックアウトするために
+``switch`` はコミットされた変更を廃棄するので、ローカルにコミットされているが最も最近\
+バインドされたブランチにまだコミットされていない変更が存在する場合意図的に失敗します。
+これらの変更を本当に廃棄したいのであれば、 ``--force`` オプションを使います。
+
+
+軽量型チェックアウトを切り替える
+----------------------------------
+
+軽量型チェックアウトでは、ローカルのコミットは存在せず、 ``switch`` は\
+作業ツリーが関連づけられたブランチを効率よく選びます。
+1つの可能なセットアップ方法は、ローカルツリーなしのリポジトリと軽量\
+チェックアウトを組み合わせて使うことです。
+これによって取り組むものを簡単に切り替えることができます。例です::
+
+ bzr init-repo --no-trees PROJECT
+ cd PROJECT
+ bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+ bzr checkout --lightweight trunk my-sandbox
+ cd my-sandbox
+ (hack away)
+
+この例のこの範囲でtrunk ``.bzr`` ディレクトリを持ちますがそこでの\
+ブランチとしての作業ツリーはツリーなしのリポジトリで作られたことに\
+注意してください。必要な数だけブランチを入手もしくは作成して必要に\
+応じてそれらの間で切り替えることができます。例です::
+
+ (my-sandboxの中にいることを前提とする)
+ bzr branch bzr+ssh://centralhost/srv/bzr/PROJECT/PROJECT-1.0 ../PROJECT-1.0
+ bzr switch ../PROJECT-1.0
+ (fix bug in 1.0)
+ bzr commit -m "blah, blah blah"
+ bzr switch ../trunk
+ (go back to working on the trunk)
+
+注: ブランチはローカルのみのものでも、(``checkout`` で作るか ``branch``
+でそれらを作った後で ``bind`` を使うことで)リモートのブランチにバインド\
+されたものでも可能です。
diff --git a/doc/ja/user-guide/reviewing_changes.txt b/doc/ja/user-guide/reviewing_changes.txt
new file mode 100644
index 0000000..c4ebf35
--- /dev/null
+++ b/doc/ja/user-guide/reviewing_changes.txt
@@ -0,0 +1,57 @@
+変更をレビューする
+==================
+
+リープする前にロックする
+-------------------------
+
+作業が完了したら、恒久的に記録することに先駆けて変更をレビューするのはよい考えです。
+この方法で、何を意図しているのかをコミットすることを確認できます。
+
+2つのbzrコマンド: **status** と **diff** はとりわけ便利です。
+
+bzr status
+----------
+
+ **status** コマンドは最後のリビジョン以降に作業ディレクトリに行われた変更内容を伝えます::
+
+ % bzr status
+ modified:
+ foo
+
+``bzr status`` は 変更されないもしくは無視される "つまらない" ファイルを隠します。
+statusコマンドはチェックするためにオプションとしてファイルもしくはディレクトリの名前を渡すことができます。
+
+bzr diff
+--------
+
+The **diff** コマンドはすべてのファイルへの変更の全文を標準のunified diffとして表示します。
+これは ''patch''、 ''diffstat''、 ''filterdiff'' と ''colordiff''といった多くのプログラムを通してパイプで引き渡すことができます::
+
+ % bzr diff
+ === added file 'hello.txt'
+ --- hello.txt 1970-01-01 00:00:00 +0000
+ +++ hello.txt 2005-10-18 14:23:29 +0000
+ @@ -0,0 +1,1 @@
+ +hello world
+
+
+``-r`` オプションによって、ツリーは前のリビジョン、もしくは示された2つのリビジョンの違いを表示します::
+
+ % bzr diff -r 1000.. # r1000 からの全ての変更
+ % bzr diff -r 1000..1100 # 1000 から 1100 までの変更
+
+1つのリビジョンの変更だけを見たい場合は、 ``-c`` オプションを利用します。
+
+::
+
+ % bzr diff -c 1000 # r1000 による変更
+ # -r999..1000 と同じ意味
+
+``--diff-options`` オプションによってbzrは外部のdiffプログラムにオプションを渡して実行します。例です::
+
+ % bzr diff --diff-options --side-by-side foo
+
+プロジェクトの中には新旧のファイルのためのパスの始めで接頭辞を表示するためにパッチを好むところもあります。
+``--prefix`` オプションはそのような接頭辞を提供するために使われます。
+ショートカットとして、 ``bzr diff -p1`` は ``patch -p1`` コマンドで機能する形式を生み出します。
+
diff --git a/doc/ja/user-guide/sending_changes.txt b/doc/ja/user-guide/sending_changes.txt
new file mode 100644
index 0000000..14e114b
--- /dev/null
+++ b/doc/ja/user-guide/sending_changes.txt
@@ -0,0 +1,65 @@
+変更を送信する
+===============
+
+動機
+-----
+
+多くの分散型のシナリオでは、開発者にとってURLを公開することでタスクブランチを\
+共有することが常に現実的であるとは限りません。
+たとえば、開発者が在宅で一晩中作業をする場合、ゲートキーパーが別のタイムゾーンで\
+レビューしてマージしたいときに開発者はタスクブランチに十分にアクセスできません。
+
+Bazaarは手助けする巧妙な機能: *マージディレクティブ* を提供します。
+
+マージのディレクティブを理解する
+---------------------------------
+
+マージディレクティブを"ミニブランチ" - ブランチが作成された後の成長部分 -
+として考えることができます。
+これは変更点を記したソフトウェアパッチですが、追加情報として中間コミット、\
+リネームとデジタル署名のようなメタデータがつきます。
+
+別の実用的なメタファはパケットケーキ: レシピと必要な材料を持った\
+マージディレクティブです。
+具体的にいえば、材料とはブランチ上で加えられた全ての変更のメタデータで、\
+レシピとはそれらの変更点をどうやってマージするかで、 ``merge`` コマンドが\
+共通の祖先を選ぶのに利用する情報です。
+
+それらをどのように考えるのであれ、マージディレクティブはよいものです。
+これらは簡単に作れて、メールに添付して送信するのに最適で、受け取った後で\
+ブランチと同じように処理できます。
+
+マージディレクティブを作る
+-----------------------------
+
+マージディレクトリを作りオプションとして送信するためには、 ``send`` コマンドを使います。
+
+デフォルトでは、 ``send`` はマージディレクティブを ブランチのための "投稿アドレス" 、
+通常はリード開発者もしくは開発メーリングリストにEメールを送信します。
+オプションなしの ``send`` はマージディレクティブを作り、Eメールツールを作動させて添付し、\
+少しの説明文を追加するための準備をします。
+(この設定方法の詳細に関してはオンラインヘルプの ``send`` と
+リファレンスマニュアルの `構成設定 <../user-reference/index.html#configuration-settings>`_
+を参照)
+
+大抵のプロジェクトではパッチ付きのメールに説明文を追加し、パッチの理由と内容を説明します。
+これによってレビューワは行単位の差分に入る前にいくらかの事情を理解できます。
+
+代わりに、 ``--output`` (or ``-o``) オプションが渡されると、 ``send``
+はマージディレクティブをファイルに書くので、あなた自身にメールを送り、
+それを検査し、後の使用のために保存できます。
+``-`` の出力ファイルが渡されると、ディレクティブはstdoutに書き込まれます。例です::
+
+ cd X-fix-123
+ bzr send -o ../fix-123.patch
+
+
+マージのディレクティブを適用する
+---------------------------------
+
+``merge`` と ``pull`` コマンドを使うことでマージディレクティブはブランチと同じ方法で\
+適用できます
+
+これらはBazaarを使わない上流のプロジェクトとコミュニケーションをするときにも便利です。
+とりわけ、マージディレクティブ内の変更全体のプレビューは無地のソフトウェアパッチの\
+ようになるので、たとえば彼らは ``patch -p0`` を使用してそれらを適用できます。
diff --git a/doc/ja/user-guide/server.txt b/doc/ja/user-guide/server.txt
new file mode 100644
index 0000000..398cd02
--- /dev/null
+++ b/doc/ja/user-guide/server.txt
@@ -0,0 +1,108 @@
+スマートサーバーを稼働させる
+============================
+
+BazaarはHTTP、FTPもしくはSFTPを通して動作するので特化したサーバーは\
+必須ではありません。
+SSH、inetd、もしくは専用モードで起動できるスマートサーバー(smart server)\
+の選択肢があります。
+
+ダムサーバー
+-------------
+
+HTTP、FTP、SFTPとHTTP-WebDAVを"ダム(dumb)"サーバーとして記述します。
+これらはBazaarに支援を提供しないからです。
+これらのプロトコルのどれかを通してBazaarリポジトリを利用できるようにする場合、
+Bazaarはリモートからの読み込みを許可します。
+実行しているBazaarコマンドの中でブランチへのURLを入力するだけです。::
+
+ bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
+
+BazaarはFTP、SFTPと(プラグインを通した)HTTP-WebDAVを通した書き込みをサポートします。
+
+ハイパフォーマンスなスマートサーバー
+-------------------------------------
+
+ハイパフォーマンスなスマートサーバー(hpss - high-performance smart server)は\
+いくつかのオペレーションをダムサーバーよりも遙かに高速に実行します。
+開発者がパフォーマンスのチューニングを継続するので、将来のリリースでは\
+スマートサーバーを利用することで改善されるオペレーションの範囲は増えます。
+
+高度なセキュリティの維持を可能にするために、
+デフォルトでは現在のスマートサーバーはリードオンリーになります。
+読み込みと書き込み権限を有効にするには、 ``--allow-writes`` で動かします。
+SSHアクセスメソッドを利用するとき、bzrは ``--allow-writes`` オプションで\
+自動的に実行します。
+
+次はスマートサーバーの代替の設定方法を説明します。
+
+SSH
+~~~
+
+SSHを通してBazaarを利用する際にサーバー上の特別な設定は必要ありません。
+サーバーに Bazaar がインストールされていれば、 ``bzr+ssh`` の URL を
+利用することができます。 例::
+
+ bzr log bzr+ssh://host/path/to/branch
+
+`bzr` がサーバーのシステムワイドな場所にインストールされていない場合、
+リモートの `bzr` がどこにあるかをローカルの `bzr` に教える必要があるかも
+しれません。 ::
+
+ BZR_REMOTE_PATH=~/bin/bzr bzr log bzr+ssh://host/path/to/branch
+
+``BZR_REMOTE_PATH`` 環境変数はリモートシステムで `bzr` が起動する方法を調整します。
+デフォルトでは単に `bzr` として起動するので、 `bzr` 実行ファイルはデフォルトの\
+検索パス上にあることが要求されます。
+この設定を場所ごとの設定ファイルである ``locations.conf`` に書いて
+永続化することもできます。
+
+SFTP と同じく、 ``~`` で始まるパスはホームディレクトリからの相対パスになります。
+例えば ``bzr+ssh://example.com/~code/proj`` のようになります。
+加えて、 ``~user`` は user のホームディレクトリからの相対パスになります。
+
+inetd
+~~~~~
+
+この例では ``/srv/bzr/repo/branchname`` にブランチがある ``/srv/bzr/repo`` 内の
+共用リポジトリ用に専用ユーザーの `bzruser` で `bzr` を実行する方法を示しています。
+
+inetdからBazaarサーバーを動かすにはinetd.confエントリが必要です::
+
+ 4155 stream TCP nowait bzruser /usr/bin/bzr /usr/bin/bzr serve --inet --directory=/srv/bzr/repo
+
+クライアントコマンドを実行するとき、提供するURLは
+inetd.confに渡される ``--directory`` オプションに相対的な `bzr://` です::
+
+ bzr log bzr://host/branchname
+
+可能であれば、 ``~`` や ``~user`` で始まるパスは ``bzr+ssh`` と同じように展開されますが、
+``bzr serve`` に指定された ``--directory`` オプションの外にあるホームディレクトリには
+アクセスできません。
+
+専用サーバー
+~~~~~~~~~~~~~
+
+このモードはinetdモードと同じパスとURLのふるまいを持ちます。
+特定のユーザーとして実行するには、 ``su`` を使うもしくはそのユーザーとしてログインします。
+
+この例では公式のポート番号の `4155` 上でbzrを稼働しすべてのインターフェイス上でリスンします。
+これによってポート `4155` 上のマシンに到達できる世界のどこからでも接続できます。
+
+サーバー::
+
+ bzr serve --directory=/srv/bzr/repo
+
+クライアント::
+
+ bzr log bzr://host/branchname
+
+この例では `localhost` のポート `1234` で ``bzr serve`` が実行されます。
+
+サーバー::
+
+ bzr serve --listen=localhost --port=1234 --directory=/srv/bzr/repo
+
+クライアント::
+
+ bzr log bzr://localhost:1234/branchname
+
diff --git a/doc/ja/user-guide/setting_up_email.txt b/doc/ja/user-guide/setting_up_email.txt
new file mode 100644
index 0000000..9ff5d8a
--- /dev/null
+++ b/doc/ja/user-guide/setting_up_email.txt
@@ -0,0 +1,95 @@
+Eメールを設定する
+=================
+
+.. Bazaarでコミット用のEメールを指定するさまざまな方法の説明です。
+
+なぜBazaarでEメールアドレスをセットアップするのか?
+---------------------------------------------------
+
+リビジョンが作成されたとき誰がどのリビジョンをコミットしたのかわかるように
+Bazaarは指定されたEメールアドレスをリビジョンに保存します。
+Eメールアドレスは検証されないので、それゆえ 偽造できるので、プロジェクトに関わる人々を信用しなければなりません。
+
+加えて、リビジョンのEメールアドレスはクレジットかつ/もしくは注釈に関してリビジョンの筆者とコンタクトをとる別の方法を提供します。
+
+Eメールアドレスをセットアップする方法
+--------------------------------------
+
+Eメールアドレスが設定されていない場合、Bazaarはユーザー名とホスト名に基づいて推測を試みます。
+これは望む状況ではないかもしれないので、Bazaarに使うメールを伝える方法は3つ存在します:
+
+いくつかの設定ファイルの1つにEメールを設定できます。
+他の設定値のように、 ``bazaar.conf`` で一般的な設定として設定できます。
+特定のブランチ、もしくは複数のブランチの一式用に値を上書きしたい場合、 ``locations.conf`` を利用できます。
+``.bzr/branch/branch.conf`` も動作しますが、
+他の人であってもそのブランチへのすべてのコミットで同じEメールアドレスが使われます。
+
+優先順位は
+
+ 1. ``BZR_EMAIL`` 環境変数が設定されている場合
+ #. Eメールが現在のブランチの ``locations.conf`` ファイルに対して設定されている場合。
+ #. Eメールが現在のブランチの ``.bzr/branch/branch.conf`` ファイルに設定されている場合。
+ #. Eメールがデフォルトの ``bazaar.conf`` 設定ファイルで設定されている場合。
+ #. `EMAIL` 環境変数が設定されている場合
+ #. Bazaarはユーザー名とホスト名から推測しようとします。
+
+Bazaarが現在のEメールと考えるものを確認するには、 ``whoami`` ("who am i?") コマンドを使います::
+
+ % bzr whoami
+ Joe Cool <joe@example.com>
+
+'whoami'コマンドでEメールを設定する
+------------------------------------
+
+Eメールをグローバルに設定するにはwhoamiコマンドを使用します::
+
+ % bzr whoami "Joe Cool <joe@example.com>"
+
+もしくは現在のブランチのみの場合::
+
+ % bzr whoami --branch "Joe Cool <joe@example.com>"
+
+これらのコマンドによってグローバルな ``bazaar.conf`` もしくはブランチの ``branch.conf`` ファイルがそれぞれ修正されます。
+
+デフォルトの設定ファイルでEメールを設定する
+--------------------------------------------
+
+デフォルトのiniファイルを使うには、 ``bazaar.conf`` ファイル
+(Unix では ``~/.bazaar/`` 、Windowsでは ``%APPDATA%\bazaar\2.0\`` )を作成し編集して
+下記で示すようにEメールアドレスを設定します。
+DEFAULTは大文字と個別を区別して、大文字でなければならないことに注意をお願いします。
+::
+
+ [DEFAULT]
+ email=Your Name <name@isp.com>
+
+
+iniファイルのフォーマットの詳細情報に関しては、Bazaarユーザーリファレンスの
+`構成設定 <../user-reference/index.html#configuration-settings>`_ を参照してください。
+
+ブランチ単位でEメールを設定する
+--------------------------------
+
+2番目のアプローチは ``locations.conf`` 設定ファイルを使用してブランチごとにEメールを設定する方法です::
+
+ [/some/branch/location]
+ email=Your Name <name@other-isp.com>
+
+これによってブランチのEメールアドレスは ``/some/branch/location`` に設定され、
+上記の ``bazaar.conf`` で指定されたデフォルトの値を上書きします。
+
+環境変数を通してEメールを設定する
+---------------------------------
+
+Bazaarが利用する最後の方法は ``BZR_EMAIL`` と ``EMAIL`` 環境変数 に対するチェックです。
+一般的に、スクリプトのコンテキストでEメールを上書きするためにこの方法を利用できます。
+一般的なデフォルトの値に設定したい場合、上記のiniの方法を参照して下さるようお願いします。
+
+スパムに関する懸念事項
+-----------------------
+
+スパムの標的にされないようにEメールアドレスを共有したくない人達がいます。
+公開された場所で自分でブランチもしくはチェンジセットを公開しない限り、BazaarはけっしてEメールアドレスを露出しません。
+他の人があなたに作業内容に関して連絡できるように実際のアドレスを使うことを *強く* お勧めしますが、必須ではありません。
+メールアドレスは難読にしたり、宛先がわからず戻ってくるようにする、もしくは `spamgourmet.cm` のような
+アンチスパムサービスの検査をうけさせたりします。
diff --git a/doc/ja/user-guide/shared_repository_layouts.txt b/doc/ja/user-guide/shared_repository_layouts.txt
new file mode 100644
index 0000000..9fbd98a
--- /dev/null
+++ b/doc/ja/user-guide/shared_repository_layouts.txt
@@ -0,0 +1,363 @@
+共用レポジトリのレイアウト
+===========================
+
+Bazaarは共用ブランチ内部のブランチのレイアウトを柔軟に決められるように設計されました。
+この柔軟性によってユーザーはBazaarを自分のワークフローに合わせることができますが、\
+"よい"レイアウトとは何かということを疑問に持つようになります。
+ここでは代わりになるものをいくつか説明しそれぞれの利点を検討します。
+
+言及すべき重要な点はよいレイアウトは"一般的な"ユーザーが理解できるように
+ブランチの内容を何らかの形でハイライトします。
+SVNにおいて これは "``trunk/``" ブランチであると考えられ、
+大抵のレイアウトではこの命名規約が守られています。
+これを "``mainline``" もしくは "``dev``" と呼ぶ人もいれば、
+CVSから来た人々はしばし "``HEAD``" と言及します。
+
+
+"SVN形式" (``trunk/``, ``branches/``)
+---------------------------------------
+
+SVNからやってきた人々は次のような"標準的な"プロジェクトのレイアウトに慣れています::
+
+ repository/ # リポジトリ全体
+ +- trunk/ # 開発のメインライン
+ +- branches/ # コンテナディレクトリ
+ | +- foo/ # 開発中のfoo機能用ブランチ
+ | ...
+ +- tags/ # コンテナディレクトリ
+ +- release-X # 特定のリリースバージョンをマークするために専用ブランチ
+ ...
+
+Bazaarでは、これは完全に適切なレイアウトです。
+SVNからやって来た人が慣れ親しめることが利点で\
+開発の焦点を当てる場所が明確になります。
+
+同じリポジトリで複数のプロジェクトを持つとき、\
+SVNのレイアウトは何を行うのか少し不透明です。
+
+
+``project/trunk``
+~~~~~~~~~~~~~~~~~
+
+SVN用の望ましい方法はプロジェクトごとにレイアウト用のトップレベルのディレクトリを用意することです::
+
+ repository/ # リポジトリ全体
+ +- project1/ # コンテナディレクトリ
+ | +- trunk/ # project1の開発のメインライン
+ | +- branches/ # コンテナディレクトリ
+ | +- foo/ # project1のfoo機能の開発用ブランチ
+ | ...
+ |
+ +- project2/ # project2用のコンテナ
+ +- trunk/ # project2用のメインライン
+ +- branches/ # project2のブランチ用のコンテナ
+
+
+これはBazaarでも機能します。
+しかしながら、Bazaarでリポジトリを作るのは簡単で( ``bzr init-repo`` )、
+それらの主要な恩恵を受けられるのは複数のブランチが共通の祖先を共有するときです。
+
+ですのでBazaarに対して望ましい方法は次のとおりです::
+
+ project1/ # project1用のリポジトリ
+ +- trunk/ # project1の開発のメインライン
+ +- branches/ # コンテナディレクトリ
+ +- foo/ # project1のfoo機能の開発用ブランチ
+ ...
+
+ project2/ # project2用のリポジトリ
+ +- trunk/ # project2用のメインライン
+ +- branches/ # project2のブランチ用のコンテナ
+
+
+``trunk/project``
+~~~~~~~~~~~~~~~~~
+
+SVNで次のようなレイアウトを利用するプロジェクトもたまにあります::
+
+ repository/ # リポジトリ全体
+ +- trunk/ # コンテナディレクトリ
+ | +- project1 # project1用のメインライン
+ | +- project2 # project2用のメインライン
+ | ...
+ |
+ +- branches/ # コンテナ
+ +- project1/ # コンテナ (?)
+ | +- foo # project1の'foo'ブランチ
+ +- project2/
+ +- bar # project2の'bar'ブランチ
+
+
+次のレイアウトはちょっと変形させたものです::
+
+ repository/ # リポジトリ全体
+ +- trunk/ # コンテナディレクトリ
+ | +- project1 # project1用のメインライン
+ | +- project2 # project2用のメインライン
+ | ...
+ |
+ +- branches/ # コンテナ
+ +- project1-foo/ # project1の'foo'ブランチ
+ +- project2-bar/ # project2の'bar'ブランチ
+
+"``trunk/``" 全体をチェックアウトすることで、すべてのプロジェクト用の\
+メインラインを入手できるようにすることが、このレイアウトが採用されている理由だと\
+筆者は考えます。
+
+このレイアウトはBazaarでも使えますが、一般的にお勧めできません。
+
+ 1) 一回の ``bzr branch/checkout/get`` は一つのブランチを作ります。
+ 単独のコマンドですべてのメインラインを入手する利点が得られません。 [1]_
+
+ 2) ``repository/trunk/foo`` が ``foo`` プロジェクトの ``trunk`` か
+ ``trunk`` ブランチの単なる ``foo`` ディレクトリなのか明らかではありません。
+ この混乱の一部はSVNによるものです。
+ SVNはプロジェクトのブランチ用に使う1つのプロジェクトのファイルに対して同じ"名前空間"を使うからです。
+ Bazaarにおいて、プロジェクトを構成するファイルの明確な定義、もしくはブランチの位置の対立軸があります
+ (ブランチごとに唯一の ``.bzr/`` ディレクトリか、チェックアウトの中にたくさんの
+ ``.svn/`` ディレクトリかという対立軸です)
+
+.. [1] 注: `NestedTreeSupport`_ は"メタプロジェクト"を作成する方法を提供します。
+ メタプロジェクトはリポジトリのレイアウトにかかわらず複数のプロジェクトを集約します。
+ 1つのプロジェクトを ``bzr checkout`` すれば、必要なサブプロジェクトがすべて手に入ります。
+
+.. _NestedTreeSupport: http://wiki.bazaar.canonical.com/NestedTrees
+
+
+入れ子形式 (``project/branch/sub-branch/``)
+---------------------------------------------
+
+SVNではできない、Bazaarによる別のスタイルは、ブランチ同士を\
+入れ子にすることです。
+Bazaarは作業ツリーなしのリポジトリ作成(``--no-trees``)をサポート\
+(と推奨)しているのでこのスタイルが可能になります。
+作業ファイルはブランチの設置場所に混ぜられていないので、 好きな名前空間にブランチを設置できます。
+
+1つの可能性は次のとおりです::
+
+ project/ # リポジトリ全体、*と* プロジェクトのメインラインのブランチ
+ + joe/ # 開発者Joeの開発のプライマリブランチ
+ | +- feature1/ # 開発者Joeのfeature1開発ブランチ
+ | | +- broken/ # feature1を開発するためのステージングブランチ
+ | +- feature2/ # Joeのfeature2開発ブランチ
+ | ...
+ + barry/ # Barryの開発ブランチ
+ | ...
+ + releases/
+ +- 1.0/
+ +- 1.1.1/
+
+このレイアウトのアイディアはブランチ用の階層的なレイアウトを作ることです。
+変更はたいていより上位の名前空間のブランチへと流れていきます。
+また、このレイアウトではユーザーに独自の作業をするための場所も提供します。
+このレイアウトの素晴らしい点の1つは、グローバルな ``branches`` 名前空間を\
+散らかさずにミニブランチを置けるので、ブランチ作成が"手軽"になることです。
+
+このレイアウトのもう一つの利点は、ブランチの名前の中で詳細な内容を指定する際に\
+繰り返しが減ることです。
+
+例です::
+
+ bzr branch http://host/repository/project/branches/joe-feature-foo-bugfix-10/
+
+上と下を比較します::
+
+ bzr branch http://host/project/joe/foo/bugfix-10
+
+
+また、 ``repository/project/branches/`` ディレクトリの中のリストがあれが何かわかるかもしれません::
+
+ barry-feature-bar/
+ barry-bugfix-10/
+ barry-bugfix-12/
+ joe-bugfix-10/
+ joe-bugfix-13/
+ joe-frizban/
+
+Versus こういったブランチが開発者のディレクトリに分散している。
+ブランチの数が少なければ、 ``branches/`` は一見するだけですべての\
+ブランチが見えるという素晴らしい利点があります。
+ブランチの数が多ければ、 ``branches/`` はすべてのブランチが\
+見えてしまうというはっきりした欠点があります。
+(調べるブランチが100あるとき、興味のあるブランチを見つけるのが難しくなります)。
+
+入れ子ブランチはたくさんのブランチよりもスケーラブルのようです。
+しかしながら、それぞれの個別のブランチは見つけにくいです。
+(たとえば"Joeはfoo機能ブランチでバグ修正10に取り組んでいるのか、\
+それともbarの機能ブランチを取り組んでいるのか?")
+
+他の小さな利点は次のようなものです::
+
+ bzr branch http://host/project/release/1/1/1
+ もしくは
+ bzr branch http://host/project/release/1/1/2
+
+1.1.1と1.1.2のリリースを示します。
+これはリリースする数と一度に見られる能力よりも分割する方がゲインが多いかによります。
+
+
+ステータスによる種類分け (``dev/``, ``merged/``, ``experimental/``)
+---------------------------------------------------------------------
+
+ブランチをbreak upする他の方法はこれらを現在のステータス順でソートすることです。
+そうするとレイアウトは次のようになります::
+
+ project/ # レイアウト全体
+ +- trunk/ # 開発に焦点を当てたブランチ
+ +- dev/ # 進行中の作業用コンテナディレクトリ
+ | +- joe-feature1 # Joeの現在のfeature-1ブランチ
+ | +- barry-bugfix10 # bugfix 10に対するBarryの作業内容
+ | ...
+ +- merged/ # これらのブランチがマージされたことを示すコンテナ
+ | +- bugfix-12 # すでにマージされたバグ修正
+ +- abandonded/ # 'dead-end'と見なされているブランチ
+
+
+これはたくさんの利点と欠点があります。
+あまり多くない数のアクティブに開発されているブランチを見ることができるか、\
+今までに作られた全てのブランチが見えるかという違いがあります。
+古いブランチは削除しない限り失われませんが、別ディレクトリへと整理されるので\
+たいていの場合お目当てのブランチを見つけやすくなります。
+(反対に、古いブランチは見つけにくくなります)。
+
+このレイアウトで最大の欠点、ブランチが移動することです。
+誰かが ``project/dev/new-feature`` ブランチをフォローしているとき、
+そのブランチが ``trunk/`` にマージされると ``project/merged/new-feature``
+に移動するので ``bzr pull`` が突然機能しなくなります。
+この回避策はいくつかあります。
+1つは利用者を導くために古いブランチから新しいブランチにリクエストする\
+HTTPリダイレクトを使うことです。
+``bzr`` >= 0.15 ではユーザーに ``http://old/path が http://new/path``
+にリダイレクトされることを教えてくれます。
+しかしながら、HTTP以外の方法(SFTP、ローカルファイルシステム、など)を\
+通してブランチにアクセスしている場合は役に立ちません。
+
+一時的なリダイレクト用にシンボリックリンクを利用することも可能です
+(シンボリックリンクがリポジトリ内にある限りトラブルはほんのわずかしかありません)。
+しかし、シンボリックリンクを結局削除したくなったり、散乱の削減の恩恵を得られません。
+シンボリックリンクの代わりの別の可能性は ``BranchReference`` を使うことです。
+``bzr`` コマンドを通してこれらを作るのは現時点では難しいですが、便利だと思う人がいれば変わるかもしれません。
+これは実際には `Launchpad`_ が ``bzr checkout https://launchpad.net/bzr`` をできるようにしている方法です。
+``BranchReference`` は機能的にはシンボリックリンクですが、他のURLの参照ができます。
+相対パスによる参照ができるように拡張されれば、HTTP、SFTP、ローカルパスを通しても\
+動作するでしょう。
+
+.. _Launchpad: https://launchpad.net
+
+
+日付/リリース/その他で種類分け (``2006-06/``, ``2006-07/``, ``0.8/``, ``0.9``)
+------------------------------------------------------------------------------
+
+スケーラビリティを可能にする別の方法は"現在の"ブランチのブラウジングを許可することです。
+基本的に、活発に開発されるブランチは新しく作られ古いブランチはマージもしくは\
+廃棄されることを前提とします。
+
+基本的に日付レイアウトは次のようになります::
+
+ project/ # projectリポジトリ全体
+ +- trunk/ # 一般的なメインライン
+ +- 2006-06/ # この月に作成されたブランチ用のディレクトリのコンテナ
+ | +- feature1/ # "project"の"feature1"用ブランチ
+ | +- feature2/ # "project"の"feature2"用ブランチ
+ +- 2005-05/ # 異なる月に作成されるブランチ用のコンテナディレクトリ
+ +- feature3/
+ ...
+
+これは "私の新しいブランチをどこに設置すればいいの?" という質問に素早く答えてくれます。
+機能が長期間開発されるのであれば、ブランチを最新の日付にコピーして、\
+そこで作業を続けることも道理にかなっています。
+最新の日付と、そこからのさかのぼっていくことで活発なブランチを見つけることができます。
+(小さな欠点は 大抵のディレクトリリストは古い順にソートされているので、\
+多くの場合新しいブランチにたどり着くために余計なスクロールが必要になることです)。
+古いブランチを新しい位置にコピーしたくない場合、ブランチを探すのが面倒になるのも欠点です。
+
+別の候補は、リリースをターゲットにしたものです::
+
+ project/ # リポジトリ概要
+ +- trunk/ # メインラインの開発ブランチ
+ +- releases/ # リリースブランチ用のコンテナ
+ | +- 0.8/ # リリース0.8のブランチ
+ | +- 0.9/ # リリース0.9のブランチ
+ +- 0.8/ # リリース0.8をターゲットとするブランチ用のコンテナ
+ | +- feature1/ # 0.8にマージする予定の"feature1"用のブランチ
+ | +- feature2/ # "リリース0.8をターゲットとしたfeature2"用のブランチ
+ +- 0.9/
+ +- feature3/ # リリース0.9をターゲットとした"feature3"用のブランチ
+
+
+その派生として、ブランチが ``0.9`` ディレクトリに入っていることが 0.9に *向けた*
+ブランチであることではなく 0.9 *から* 派生したブランチであることを意味するように\
+することや、 ``0.8/release`` が0.8ブランチの公式リリースであることを意味するように\
+することが考えられます。
+
+一般的なアイディアはリリースをターゲットにすることで、何のブランチがマージ\
+されるのを待っているのか調べることができます。
+このレイアウトはブランチの状態(開発中なのか、終了してレビューを待っているのか)\
+に関する情報を提供しません。
+これは履歴を隠す効果もあり、日付ベースの種類分けと同じような利点と欠点を持っています。
+
+シンプルな開発者名 (``project/joe/foo``, ``project/barry/bar``)
+----------------------------------------------------------------
+
+別の利用できるレイアウトは、開発者ごとにディレクトリを割り当てて、\
+その下にブランチのためのサブディレクトリを作ることです。次のようになります::
+
+ project/ # リポジトリ全体
+ +- trunk/ # メインラインのブランチ
+ +- joe/ # Joeのブランチ用のコンテナ
+ | +- foo/ # Joeの"project"の"foo"ブランチ
+ +- barry/
+ +- bar/ # Barryの"project"の"bar"ブランチ
+
+このアイデアでは、branchは入れ子になっておらず、branchは開発者によってのみ\
+グループ化されます。
+
+`Launchpad`_ で使われている派生系はこのようになっています::
+
+ repository/
+ +- joe/ # Joeのブランチ
+ | +- project1/ # Joeのブランチである"project1"用のコンテナ
+ | | +- foo/ # Joeの"project1"の"foo"ブランチ
+ | +- project2/ # Joeの"project2"ブランチ用のコンテナ
+ | +- bar/ # Joeの"project2"の"bar"ブランチ
+ | ...
+ |
+ +- barry/
+ | +- project1/ # Barryの"project1"のブランチ用のコンテナ
+ | +- bug-10/ # Barryの"project1"の"bug-10"ブランチ
+ | ...
+ +- group/
+ +- project1/
+ +- trunk/ # "project1"に焦点をあてたメイン開発
+
+
+このレイアウトではそれぞれの開発者が取り組んでいるものを簡単に見ることができます。
+焦点のブランチは"group" ディレクトリに保存されます。
+これによって"グループ"が取り組んでいるブランチを見分けられます。
+
+これによって異なる人々の作業内容をそれぞれ分離できますが、\
+"プロジェクトX用のすべてのブランチ"を見つけるのが難しくなります。
+`Launchpad`_ はデータベースバックエンドを伴う素晴らしいウェブインターフェイス\
+を提供していて、"view"をこのレイアウトのトップに追加することでこの欠点を補っています。
+これはそれぞれの個人が "``~/public_html``" ディレクトリを持ち、そこで独自の\
+ウェブページを公開する個人用ホームページのモデルに近いです。
+一般的に、集中型のプロジェクト用に共用リポジトリを作成するとき、\
+個人単位で分割してからプロジェクト単位に分割することを望まないでしょう。
+通常はプロジェクト単位で分割してから個人単位で分割するとよいでしょう。
+
+要約
+-----
+
+最後に、誰にとってもうまくいく唯一の命名規則はありません。
+開発者の人数、新しいブランチが作成される頻度、ブランチのライフサイクルなどに\
+よって異なります。
+自身に問いかける質問は次のとおりです:
+
+ 1) 寿命の長い少数のブランチを作るか、もしくはたくさんの"ミニ"機能ブランチを作るか
+ (加えて: ミニ機能ブランチをたくさん *作りたい* が現在のVCSでは苦痛なのでできないのではないか?)
+
+ 2) 1人で開発しているのか、大きなチームか?
+
+ 3) チームであれば、一般的に全員が同時に同じブランチに取り組むことを計画しているか?
+ もしくは人々が追跡することを想定した"安定"ブランチを持つか。
+
diff --git a/doc/ja/user-guide/shelving_changes.txt b/doc/ja/user-guide/shelving_changes.txt
new file mode 100644
index 0000000..d183cfe
--- /dev/null
+++ b/doc/ja/user-guide/shelving_changes.txt
@@ -0,0 +1,109 @@
+Shelving Changes
+================
+
+ときどき、作業ツリーから一時的に変更点を取り除いて、あとで元に戻したいことが\
+あるかもしれません。
+たとえば何か作業中に小さいバグフィックスを見つけてコミットする場合などです。
+Bazaarは変更を ``shelf`` (書棚)に保存する機能を持っています。
+後で変更を元に戻したくなったときは、 ``unshelve`` を使って作業ツリーに戻す\
+ことができます。
+
+たとえば、一つか複数の変更がされた作業ツリーを考えて見ます...::
+
+ $ bzr diff
+ === modified file 'description.txt'
+ --- description.txt
+ +++ description.txt
+ @@ -2,7 +2,7 @@
+ ===============
+
+ These plugins
+ -by Michael Ellerman
+ +written by Michael Ellerman
+ provide a very
+ fine-grained 'undo'
+ facility
+ @@ -11,6 +11,6 @@
+ This allows you to
+ undo some of
+ your changes,
+ -commit, and get
+ +perform a commit, and get
+ back to where you
+ were before.
+
+``shelve`` コマンドはインタラクティブにどの変更を作業ツリーに保留して\
+おきたいのかを質問します。::
+
+ $ bzr shelve
+ --- description.txt
+ +++ description.txt
+ @@ -2,7 +2,7 @@
+ ===============
+
+ These plugins
+ -by Michael Ellerman
+ +written by Michael Ellerman
+ provide a very
+ fine-grained 'undo'
+ facility
+
+ Shelve? [yNfrq?]: y
+ --- description.txt
+ +++ description.txt
+ @@ -11,6 +11,6 @@
+ This allows you to
+ undo some of
+ your changes,
+ -commit, and get
+ +perform a commit, and get
+ back to where you
+ were before.
+
+ Shelve? [yNfrq?]: n
+ Shelve 2 change(s)? [yNfrq?]', 'y'
+ Selected changes:
+ M description.txt
+ Changes shelved with id "1".
+
+もしたくさんの変更が作業ツリーにあるのであれば、 ``shelve`` コマンド\
+にファイルのリストを渡して、それらのファイルの変更だけについて質問\
+されるようにすることができます。
+変更を shelve した後に ``diff`` コマンドで作業ツリーに期待する変更だけが\
+残っていることを確認するとよいでしょう。::
+
+ $ bzr diff
+ === modified file 'description.txt'
+ --- description.txt
+ +++ description.txt
+ @@ -2,7 +2,7 @@
+ ===============
+
+ These plugins
+ -by Michael Ellerman
+ +written by Michael Ellerman
+ provide a very
+ fine-grained 'undo'
+ facility
+
+よし! - コミットする準備ができました::
+
+ $ bzr commit -m "improve first sentence"
+
+後になって、shelveした変更を作業ツリーに ``unshelve`` コマンドで\
+戻します::
+
+ $ bzr unshelve
+ Unshelving changes with id "1".
+ M description.txt
+ All changes applied successfully.
+
+もし望むのであれば、複数のアイテムをshelfに置くことができます。
+通常 ``unshelve`` が実行されるたびに最も最近 shelve された変更が\
+元に戻されます。
+明示的にどの変更を戻すのかを指定することで別の順序で unshelve する\
+こともできます。
+
+Bazaarはshelveされた後に変更があっても、shelfの変更を作業ツリーに\
+マージするので、衝突が発生するかもしれません。
+その場合は通常のマージ後と同じように衝突を解決しなければなりません。
diff --git a/doc/ja/user-guide/solo_intro.txt b/doc/ja/user-guide/solo_intro.txt
new file mode 100644
index 0000000..006a896
--- /dev/null
+++ b/doc/ja/user-guide/solo_intro.txt
@@ -0,0 +1,23 @@
+単独で始める
+=============
+
+個人の生産性を向上させるツール
+--------------------------------
+
+ツールの中には個人を生産的にする(たとえばエディタ)ためや
+チームもしくは会社全体を生産的にする(たとえばバックエンドサービス)ために設計されたものがあります。
+バージョン管理ツールは伝統的に後者の陣営にありました。
+
+Bazaarがクールであることの1つはセットアップが簡単なのでバージョン管理ツールを個人の生産性を上げるツールとして扱うことができることです。
+既知のよい状態であるかチェックする、もしくは履歴を追跡するために変更を保存したい場合、簡単に行うことができます。
+この章では方法を説明します。
+
+単独用途のワークフロー
+-----------------------
+
+あなた独自の名作を作っているのであれば、ソフトウェア、プロジェクトもしくは\
+ドキュメントの一式であれ、典型的なワークフローは次のようになります:
+
+.. image:: images/workflows_single.png
+
+チームの一員として常に作業をするとしても、この章でカバーされるタスクはあなたが行うことの基本になるので、よいスタート地点です。
diff --git a/doc/ja/user-guide/specifying_revisions.txt b/doc/ja/user-guide/specifying_revisions.txt
new file mode 100644
index 0000000..f480474
--- /dev/null
+++ b/doc/ja/user-guide/specifying_revisions.txt
@@ -0,0 +1,158 @@
+.. _specifying-revisions:
+
+リビジョンを指定する
+====================
+
+.. _revision-identifiers-and-ranges:
+
+リビジョンの識別子と範囲
+-------------------------
+
+Bazaarは1つのリビジョンもしくはリビジョンの範囲を指定するための豊富な表現方法を持ちます。
+リビジョンの範囲を指定するには、上限と下限を ``..`` のシンボルで区切ります。例です::
+
+ $ bzr log -r 1..4
+
+境界値の片方を省略できます::
+
+ $ bzr log -r 1..
+ $ bzr log -r ..4
+
+コマンドの中には範囲ではなく1つのリビジョンだけをとるものがあります。例です::
+
+ $ bzr cat -r 42 foo.c
+
+他の場合、範囲は必要ですが、範囲の長さを1つにします。
+これに関連したコマンドについて、 ``-c`` オプションは次のように使われます::
+
+ $ bzr diff -c 42
+
+.. _available-revision-identifiers:
+
+利用可能なリビジョンの識別子
+------------------------------
+
+リビジョン、もしくは範囲の境界、は
+下記に示される異なるフォーマットを利用して渡すことができます。
+
+ +----------------------------+--------------------------------------------+
+ | 引数の型 | 説明 |
+ +----------------------------+--------------------------------------------+
+ | *number* | リビジョン番号 |
+ +----------------------------+--------------------------------------------+
+ | **revno**:*number* | リビジョン番号 |
+ +----------------------------+--------------------------------------------+
+ | **last**:*number* | 負のリビジョン番号 |
+ +----------------------------+--------------------------------------------+
+ | *guid* | グローバルでユニークなリビジョンID |
+ +----------------------------+--------------------------------------------+
+ | **revid**:*guid* | グローバルでユニークなリビジョンID |
+ +----------------------------+--------------------------------------------+
+ | **before**:*rev* | ''rev''の左端の親 |
+ +----------------------------+--------------------------------------------+
+ | *date-value* | 渡された日付の後の最初のエントリ |
+ +----------------------------+--------------------------------------------+
+ | **date**:*date-value* | 渡された日付の後の最初のエントリ |
+ +----------------------------+--------------------------------------------+
+ | *tag-name* | 渡されたタグにマッチするリビジョン |
+ +----------------------------+--------------------------------------------+
+ | **tag**:*tag-name* | 渡されたタグにマッチするリビジョン |
+ +----------------------------+--------------------------------------------+
+ | **ancestor**:*path* | ブランチからのマージされた最新のリビジョン |
+ +----------------------------+--------------------------------------------+
+ | **branch**:*path* | 別のブランチの最新リビジョン |
+ +----------------------------+--------------------------------------------+
+ | **submit**:*path* | 投稿ブランチの共通の祖先 |
+ +----------------------------+--------------------------------------------+
+
+これらのフォーマットの手短な紹介は下記のとおりです。
+完全な詳細内容に関しては、 Bazaarユーザーリファレンスの `リビジョンの識別子`_ を参照してください。
+
+.. _リビジョンの識別子: ../user-reference/index.html#revision-identifiers
+
+番号
+~~~~~
+
+正の数は現在のブランチにおけるリビジョン番号を表します。
+リビジョン番号は ``bzr log`` の出力の中で "revno"とラベルされます。
+最初の10のリビジョンのログを表示するには::
+
+ $ bzr log -r ..10
+
+負の数は最新リビジョンから数えます。-1は最後にコミットされたリビジョンです。
+
+最新の10のリビジョンのログを表示するには::
+
+ $ bzr log -r -10..
+
+revid
+~~~~~
+
+**revid** は ``bzr log --show-ids`` や他のコマンドによって示される内部の
+リビジョンIDの指定を可能にします。
+
+例です::
+
+ $ bzr log -r revid:Matthieu.Moy@imag.fr-20051026185030-93c7cad63ee570df
+
+before
+~~~~~~
+
+**before**
+ ''rev''は''rev'' の左端の親を指定します。
+ これはリビジョンの履歴で ''rev'' の前に現れるリビジョン、
+ もしくは ''rev'' がコミットされたときに最新であったリビジョンです。
+
+''rev'' はリビジョンの識別子であり連結できます。
+
+例です::
+
+ $ bzr log -r before:before:4
+ ...
+ revno: 2
+ ...
+
+date
+~~~~
+
+**date**
+ ''value'' は真夜中もしくは指定された時刻での与えられた日付の、
+ 深夜12時か指定された時刻の後の最初の履歴エントリにマッチします。
+
+正式な値は次のとおりです:
+
+ * **yesterday**
+ * **today**
+ * **tomorrow**
+ * **YYYY-MM-DD** 書式の日付
+ * **YYYY-MM-DD,HH:MM:SS** 書式の日付/時間、2番目はオプションです (コンマに注意)
+
+"今日のログエントリすべてをください"ということを伝える適切な方法は次のとおりです::
+
+ $ bzr log -r date:yesterday..date:today
+
+Ancestor
+~~~~~~~~
+
+**ancestor**:*path*
+ 現在のブランチと異なるブランチ間の共通の祖先を指定します。
+ これはマージの目的に使われる同じ祖先です。
+
+*path* はリモートブランチのURLもしくはローカルブランチへのファイルパスになります。
+
+たとえば、 ``../parent`` からフォークされた以降のブランチで行われた変更を見るには::
+
+ $ bzr diff -r ancestor:../parent
+
+Branch
+~~~~~~
+
+branch
+ ``path`` は別のブランチの最新リビジョンを指定します。
+
+``path`` はリモートブランチのURLもしくはローカルブランチへのファイルパスです。
+
+たとえば、手元のブランチと別のブランチの間の違いを取得するには::
+
+ $ bzr diff -r branch:http://example.com/bzr/foo.dev
+
diff --git a/doc/ja/user-guide/stacked.txt b/doc/ja/user-guide/stacked.txt
new file mode 100644
index 0000000..c4ff24b
--- /dev/null
+++ b/doc/ja/user-guide/stacked.txt
@@ -0,0 +1,118 @@
+スタックブランチを利用する
+==========================
+
+.. _motivation:
+
+ユースケース
+--------------
+
+あるプロジェクトで作業しようとしていて、公開されているリポジトリに対して
+読み込みアクセスはできるものの書き込みができないとしましょう。
+公開されているリポジトリと同じホストで自分のブランチを公開したりバックアップ
+したりする場合、スタックブランチを使うことができるかもしれません。
+
+スタックブランチの他のユースケースとしては、実験的なブランチと、コード
+ホスティングサイトが挙げられます。これらのシナリオではスタックブランチの
+特性がぴったりあいます。
+
+
+スタックブランチとは?
+-------------------------
+
+スタックブランチ(stacked branch)は別の(スタック先)ブランチのリビジョンを
+見つける方法を知っています。
+スタックブランチはスタック先ブランチには存在しないユニークなリビジョンのみを
+保存することで、ブランチの作成を高速にしたり、ディスク利用効率を向上します。
+これらの観点から、スタックブランチは共用リポジトリと似ています。
+しかしながら、スタックブランチは追加の利点があります:
+
+* 新しいブランチはスタックされたブランチとは完全に異なる位置に設置できます。
+
+* スタックブランチを削除すれば(共用リポジトリだと残ってしまう)
+ リビジョンの情報も削除されます
+
+* セキュリティは共用リポジトリよりも向上しています。
+ スタック先のリポジトリはスタックブランチにコミットする開発者に対して
+ 物理的にリードオンリーだからです。
+
+
+スタックブランチを作成する
+--------------------------
+
+スタックブランチを作成するには、branchコマンドの ``stacked`` オプションを使用します。
+例です::
+
+ bzr branch --stacked source-url my-dir
+
+このコマンドによって ``my-dir`` がローカルリビジョンなしのスタックブランチ\
+として作成されます。
+定義されると、 ``source-url`` に関連づけされた公開ブランチは
+*スタックドオン(stacked on)* の位置として使われます。
+さもなければ、 ``source-url`` は *スタックドオン* の位置になります。
+
+
+スタックチェックアウトを作成する
+-----------------------------------
+
+スタックチェックアウトを直接作成する機能はまもなくサポートされる予定です。
+それまでの間、2段階の処理が必要です:
+
+1. 上記で示されたようにスタックブランチを作成する。
+
+2. ``reconfigure`` もしくは ``bind`` コマンドのどちらかを利用して
+ ブランチをチェックアウトに変換する。
+
+
+スタックブランチをプッシュする
+---------------------------------
+
+多くのプロジェクトの大部分の変更は
+*開発トランク* or *現在の安定* ブランチといった既存のブランチを基礎としています。
+これらの1つにスタックされた新しいブランチの作成は ``push`` コマンドを利用して
+次のように簡単にできます::
+
+ bzr push --stacked-on reference-url my-url
+
+このコマンドでは、 ``reference-url`` にスタックした新しいブランチを ``my-url``
+に作成し、 ``reference-url`` には無いリビジョンだけをそこに格納します。
+``my-url`` は ``reference-url`` と同じホストでも構いません。
+
+.. The following text is hidden because bug 375013 breaks the example.
+ When bug 375013 is fixed, we should unhide this text.
+ - Andrew Bennetts, 10 March 2010
+
+ローカルブランチがスタックブランチとして作成された場合、
+``push`` するには ``--stacked`` オプションを使うことが可能で
+スタック先の位置を省略できます。::
+
+ bzr branch --stacked source-url my-dir
+ cd my-dir
+ (hack, hack, hack)
+ bzr commit -m "fix bug"
+ bzr push --stacked
+
+この使い方は、上述したユースケースにマッチしています。
+
+
+スタックブランチの制限
+----------------------
+
+スタックブランチに関して覚えておくべき大事なことは、ほとんど全ての\
+オペレーションでスタック先ブランチが必要になることです。
+これは両方のブランチがローカルもしくは同じサーバーにあるときは\
+問題にはなりません。
+
+また、ほとんどの履歴がスタック先リポジトリに格納されているので、スタック先
+リポジトリへのアクセスがネットワーク経由だった場合に ``bzr log``
+のようなコマンドが遅くなるかもしれません。
+
+スタックするブランチを変更する
+-------------------------------
+
+``bzr reconfigure`` コマンドを使ってスタックドオンブランチを変更したり\
+スタックするのをやめたりすることができます。
+``bzr reconfigure --unstacked`` を実行した場合、bzrは全ての参照されているデータを\
+スタックドオンブランチからスタックされていたブランチにコピーしてくることに\
+注意してください。
+大きなレポジトリにおいては、これは時間がかかったりリポジトリサイズを増大\
+させたりします。
diff --git a/doc/ja/user-guide/starting_a_project.txt b/doc/ja/user-guide/starting_a_project.txt
new file mode 100644
index 0000000..e31596d
--- /dev/null
+++ b/doc/ja/user-guide/starting_a_project.txt
@@ -0,0 +1,48 @@
+プロジェクトを始める
+=====================
+
+既存のプロジェクトをバージョン管理する
+---------------------------------------
+
+バージョン管理下に置きたいソースコードのツリー(ドキュメントのディレクトリ)をすでにお持ちなら、
+使うコマンドは以下のとおりです::
+
+ cd my-stuff
+ bzr init
+ bzr add
+ bzr commit -m "Initial import"
+
+``bzr init`` はトップレベルのディレクトリで ``.bzr`` ディレクトリを作ります(上記の例では ``my-stuff`` )。
+次のことに注意してください:
+
+ * Bazaarは必要なすべてのものをそのディレクトリに置きます -
+ データベース、ウェブサーバー、特別なサービスをセットアップする **必要はありません**
+
+ * Bazaarは ``.bzr`` を1つのディレクトリだけに作り、他のすべてのサブディレクトリの中には作らないぐらい礼儀正しいです。
+
+``bzr add`` はバージョン管理化におくべきと考えられるすべてのファイルとディレクトリを見つけ内部で登録します。
+``bzr commit`` はこれらの内容のスナップショットとその情報をコミットメッセージと一緒に記録します。
+
+``init`` 、 ``add`` と ``commit`` に関する詳細な情報は後で提供します。
+現時点で、覚えておくべき大事なことは上記のレシピです。
+
+新しいプロジェクトを始める
+---------------------------
+
+プロジェクトをゼロから始める場合、最初の段階で空のディレクトリを作った後で上述のレシピを使うこともできます。
+後の章で詳しく探求する効率の理由から、プロジェクトのためにトップレベルでレポジトリを作り
+その中で *メイン* のブランチを入れ子にすることはよいアイディアです。次のようになります::
+
+ bzr init-repo my.repo
+ cd my.repo
+ bzr init my.main
+ cd my.main
+ hack, hack, hack
+ bzr add
+ bzr commit -m "Initial import"
+
+*main* の代わりに *trunk* もしくは *dev* のような名前を好む人もいます。
+何であれあなたにとって最も有用な意味のある名前を選んでください。
+
+``init-repo`` と ``init`` コマンドの両方はパスを引数としてとり、すでに存在していなければそのパスを作ることに留意してください。
+
diff --git a/doc/ja/user-guide/svn_plugin.txt b/doc/ja/user-guide/svn_plugin.txt
new file mode 100644
index 0000000..0a3fdc6
--- /dev/null
+++ b/doc/ja/user-guide/svn_plugin.txt
@@ -0,0 +1,108 @@
+bzr-svn
+=======
+
+概要
+-----
+
+bzr-svnによって集中型のSubversionリポジトリをまだ利用しているプロジェクトで\
+BazaarをVCSクライアントとして使うことができます。
+Subversionリポジトリへのアクセスは大部分は透明、\
+すなわちネイティブのBazaarブランチで ``bzr`` を使用するようにSubversion\
+リポジトリで大部分の ``bzr`` コマンドを直接利用できます。
+
+多くのbzr-svnユーザーは集中型のSubversionトランクのローカルミラーを作成し、\
+機能ブランチに取り組み、準備ができたときに変更をすべててSubversionに戻します。
+これによって既存のチーム規模のプロセスとSubversionの上に現在組み込まれている\
+ツール統合フックを妨げずに分散型VCSツールの多くの利点を得られます。
+本当に、これはBazaarを採用しようとしているがタイミングもしくは非技術的な\
+利用からまだ採用していないチームのための共通の暫定ステップです
+
+インストールの手引きに関しては、bzr-svnのホームページをご覧ください:
+http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion
+
+
+シンプルな例
+-------------
+
+GNOMEプロジェクトの **beagle** でのシンプルな使い方です。
+最初に、ブランチの保存用のローカルな共用リポジトリをセットアップして\
+トランクをチェックアウトします::
+
+ bzr init-repo beagle-repo
+ cd beagle-repo
+ bzr checkout svn+ssh://svn.gnome.org/svn/beagle/trunk beagle-trunk
+
+次に、フィーチャブランチを作成してハックします::
+
+ bzr branch beagle-trunk beagle-feature1
+ cd beagle-feature1
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+
+機能がクックされたとき、トランクをリフレッシュして変更をマージします::
+
+ cd ../beagle-trunk
+ bzr update
+ bzr merge ../beagle-feature1
+ bzr commit -m "Complete comment for SVN commit"
+
+トランクミラーはチェックアウトなので、それにコミットすれば実際のSubversionトランクにコミットされます。
+以上です!
+
+
+集中型のミラーを利用する
+-------------------------
+
+大きなプロジェクトに関しては、上記のレシピを調整すれば役立つことがしばしあります。
+とりわけ、初期のチェックアウトはとても遅い可能性があるので\
+プロジェクトに関するすべてのSubversionリポジトリをBazaarリポジトリに一旦インポートして、
+そのネイティブのBazaarリポジトリからブランチを作成します。
+bzr-svnはリポジトリからリポジトリへの変換を行うために ``svn-import`` コマンドを提供します。
+使い方の例です::
+
+ bzr svn-import svn+ssh://svn.gnome.org/svn/beagle
+
+中央のBazaarミラーを利用するために更新された上記からのレシピです::
+
+ bzr init-repo beagle-repo
+ cd beagle-repo
+ bzr branch bzr+ssh://bzr.gnome.org/beagle.bzr/trunk beagle-trunk
+ bzr branch beagle-trunk beagle-feature1
+ cd beagle-feature1
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+ (hack, hack, hack)
+ bzr commit -m "blah blah blah"
+ cd ../beagle-trunk
+ bzr pull
+ bzr merge ../beagle-feature1
+ bzr commit -m "Complete comment for SVN commit"
+ bzr push
+
+この場合、トランクへのコミットをしてもローカルでマージをコミットするだけです。
+マスターのSubversionトランクにコミットを戻すには、追加コマンド(``bzr push``)が必要です。
+
+注: トランクブランチで ``pull`` と ``push`` のコマンドを最初に使う際に
+これらのコマンドに関連URLを渡す必要があります。
+その後で、bzrはそれらを記憶します。
+
+このセットアップの最後のピースはSubversionのものと同期される中心のBazaarミラーを\
+Subversionのリポジトリと同期し続けるためにスクリプトを適切な場所に設置することです。
+これはcronジョブを追加したり、Subversionフックを利用するなどによって行われます。
+
+
+bzr-svnの制限
+--------------
+
+BazaarとはSubversionは異なる機能を持つ異なるツールなので\
+何らかの相互運用問題が常に存在します。
+bzr-svn 0.5.4 に関するいくつかの例です:
+
+ * Bazaarはversioned propertiesをサポートしません
+
+ * Bazaarはファイルのコピーのトラッキングをサポートしません
+
+現在の制約の一覧に関しては、bzr-svnのウェブページ、
+http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion を参照してください。
diff --git a/doc/ja/user-guide/undoing_mistakes.txt b/doc/ja/user-guide/undoing_mistakes.txt
new file mode 100644
index 0000000..802aacd
--- /dev/null
+++ b/doc/ja/user-guide/undoing_mistakes.txt
@@ -0,0 +1,152 @@
+間違いを取り消す
+================
+
+間違いは起きる
+---------------
+
+Bazaarは下記で説明されるような間違いから簡単にリカバーできるように
+設計されています。
+
+プロジェクトのリビジョンの履歴をドロップする
+---------------------------------------------
+
+思いがけず間違ったツリーをバージョン管理下に置いたとしても、 ``.bzr`` ディレクトリを削除するだけで済みます。
+
+ファイルもしくはディレクトリの登録を解除する
+---------------------------------------------
+
+バージョン管理下に置きたくないファイルを思いがけず ``add`` コマンドで登録しても、
+それを忘れるようにBazaarにそれを忘れさせるために ``remove`` コマンドを使用できます。
+
+``remove`` は修正されたファイルが削除されないよに *安全に物事を行う* ために設計されています。たとえば::
+
+ bzr add foo.html
+ (oops - didn't mean that)
+ bzr remove foo.html
+
+このコマンドは修正されたもしくは未知のファイルについてはエラーを出力します。
+ファイルを維持したいのであれば、 ``--keep`` オプションを使います。
+代わりに、ファイルを削除したいのであれば、 ``--force`` オプションを使います::
+
+ bzr add foo.html
+ (oops - didn't mean that)
+ bzr remove --keep foo.html
+ (foo.html はディスクには残るけれども、bzrには登録されない)
+
+一方で、未変更の ``TODO`` ファイルは登録が解除されエラー出力なしでディスクから削除されます::
+
+ bzr add TODO
+ bzr commit -m "added TODO"
+ (hack, hack, hack - but don't change TODO)
+ bzr remove TODO
+ (TODO ファイルは削除される)
+
+注: IDEもしくはオペレーティングシステムのファイルマネージャーを\
+利用してファイルを削除する場合、 ``commit`` コマンドはそれを削除\
+されるものとして暗黙のうちに扱います。
+
+最後のコミット以降の変更を取り消す
+----------------------------------
+
+バージョン管理ツールを使う理由の1つは作業をしている間にツリーのステータスを楽に調べられることです。
+最新の ``commit`` 以降の変更を廃棄することを決心したら、使うコマンドは ``revert`` です::
+
+ bzr revert
+
+事前の警告として、 実際にすべてが本当に廃棄されたことを確認するために
+``bzr status`` と ``bzr diff`` を最初に使うことはよい習慣です。
+
+最後のコミット以降のファイルへの変更を取り消す
+-----------------------------------------------
+
+最後のコミット以降の特定のファイルの変更を取り消したいが、ツリーの他のすべての変更を維持したい場合、
+ファイルの名前を引数として ``revert`` に渡します::
+
+ bzr revert foo.py
+
+最後のコミットを取り消す
+-------------------------
+
+意図しないコミットをしてしまったら、取り消すために ``uncommit`` コマンドを使います::
+
+ bzr uncommit
+
+``revert`` とは異なり、 ``uncommit`` は作業のツリーの内容をそのままにします。
+意図せずに間違ったエラーメッセージをコミットしてしまった場合、これは本当に重宝します::
+
+ bzr commit -m "Fix bug #11"
+ (damn - wrong bug number)
+ bzr uncommit
+ bzr commit -m "Fix bug #1"
+
+コミットを取り消す別の理由は1つもしくは複数のファイルの追加を忘れたからというものです 。
+これを避けるために、未知のファイルがツリーの中で見つかるとコミットがエラーになるように
+``commit`` を ``commit --strict`` のエイリアスにする人もいます。
+
+注: ``merge`` コマンドは次の章まで紹介しませんが、
+``uncommit`` で追加するマージをリストアすることは無意味です。
+(``uncommit`` の後で ``bzr status`` を実行するとこれらが表示されます)
+``merge`` は履歴の前の方の指定したコミットだけを効率良く取り消すためにも使われます。
+``merge`` に関する詳細な情報は
+次の章の `変更をマージする <merging_changes.html>`_
+とBazaarのユーザーリファレンスを参照してください。
+
+複数のコミットを取り消す
+------------------------
+
+複数のコミットを取り消すためには -r オプションを使います::
+
+ bzr uncommit -r -3
+
+これを行うための理由が本当にいくつかの変更を破棄したいのであるなら、
+``uncommit`` は作業ツリーを変更しないことを覚えておいてください:
+タスクを完了させることと同じようにおそらく ``revert`` コマンドを実行する必要があります。
+しかし多くの場合、履歴をそのままにしておき、最新のよい状態の内容を反映する
+新しいリビジョンを追加する方が間違いなくベターです。
+
+過去のバージョンの状態に戻す
+-----------------------------
+
+望まない変更を行ったが、コードがユーザーに公開されているのでコミットの取り消しが合理的ではない場合、
+作業ツリーを望む状態に戻すために ``revert`` を利用できます::
+
+ % bzr commit "Fix bug #5"
+ Committed revision 20.
+ (release the code)
+ (hmm - bad fix)
+ bzr revert -r 19
+ bzr commit -m "Backout fix for bug #5"
+
+この作業によってツリー全体をリビジョン19の状態に変更します。
+それ以降は新しいコミットをしていなければ、おそらくこれがあなたのしたい唯一のことです。
+新しいコミットをしている場合は、 ``revert`` はそれも消してしまいます。
+その場合は、わるい修正を取り消す代わりに
+`リバースチェリーピック <adv_merging.html#reverse-cherrypicking>`_
+を使う方がよいでしょう。
+
+注: 19のような絶対的なリビジョン番号の代わりに、
+負の数を使ってチップ(-1)と相対的なリビジョンを指定できます::
+
+ bzr revert -r -2
+
+タグを訂正する
+----------------
+
+早まってタグを定義したのなら、
+``tag`` コマンドの ``--force`` オプションを使って再定義します::
+
+ bzr tag 2.0-beta-1
+ (oops, we're not yet ready for that)
+ (make more commits to include more fixes)
+ bzr tag 2.0-beta-1 --force
+
+タグをクリアする
+-----------------
+
+タグを定義したが使いたくないのであれば、削除するために、
+``tag`` コマンドの ``--delete`` オプションを使うことができます::
+
+ bzr tag 2.0-beta-4
+ (oops, we're not releasing a 4th beta)
+ bzr tag 2.0-beta-4 --delete
+
diff --git a/doc/ja/user-guide/using_aliases.txt b/doc/ja/user-guide/using_aliases.txt
new file mode 100644
index 0000000..3e32fd8
--- /dev/null
+++ b/doc/ja/user-guide/using_aliases.txt
@@ -0,0 +1,55 @@
+エイリアスを利用する
+====================
+
+エイリアスとは?
+-----------------
+
+エイリアスは良く入力するコマンド用のショートカットを作る
+もしくはコマンド用のデフォルトを設定するための手軽な方法です。
+
+エイリアスを定義する
+---------------------
+
+コマンドのエイリアスは ``bazaar.conf`` ファイルの ``[ALIASES]`` セクションで定義されます。
+エイリアスはエイリアスの名前で始まり、等号(=)、コマンド列が続きます。
+次のコードはALIASESセクションの例です::
+
+ [ALIASES]
+ recentlog=log -r-3..-1
+ ll=log --line -r-10..-1
+ commit=commit --strict
+ diff=diff --diff-options -p
+
+上記の例の説明は次のとおりです:
+
+ * 最初のエイリアスは最新の3つのリビジョンに対するログを表示する新しい ``recentlog`` コマンドを作ります
+ * ``ll`` エイリアスは行形式で最新の10件のログエントリを表示します。
+ * ``commit`` エイリアスはツリーの中の新しいファイルが認知されない場合コミットを拒絶するデフォルトのcommitを設定します。
+ * ``diff`` エイリアスは -pオプションをdiffに追加します
+
+定義したエイリアスを利用する
+-----------------------------
+
+上記で定義されたエイリアスは次のように使われます: ::
+
+ % bzr recentlog
+ % bzr ll
+ % bzr commit
+ % bzr diff
+
+エイリアスのためのルール
+-------------------------
+
+ * コマンドライン上で新しいオプションを指定することでエイリアスに渡されるオプションの一部をオーバーライドできます。
+ たとえば、 ``lastlog -r-5..`` を実行すると 10の代わりに行ベースのログエントリが5つだけ得られます。
+ すべての論理値型のオプションは暗黙的に逆のオプションがあるので、 ``commit --no-strict`` でcommitのエイリアスをオーバーライドできます。
+
+ * エイリアスの名前をオリジナルのコマンドと同じものにすることでエイリアスは既存のコマンドの標準のふるまいをオーバーライドできます。
+ たとえば、デフォルトのコミットは ``commit=commit --strict`` で変更されます。
+
+ * エイリアスは他のエイリアスを参照できません。言い換えると エイリアスの ``lastlog`` を作りそれを ``ll`` で参照しても動作しません。
+ これは標準のコマンドをオーバーライドするエイリアスを含みます。
+
+ *   ``--no-aliases`` オプションをbzrのコマンドに渡すと実行時にエイリアスは無視されます。
+ たとえば、 ``bzr --no-aliases commit`` を実行すると ``commit --strict`` ではなく標準のcomitコマンドが実行されます。
+
diff --git a/doc/ja/user-guide/using_checkouts.txt b/doc/ja/user-guide/using_checkouts.txt
new file mode 100644
index 0000000..842dbba
--- /dev/null
+++ b/doc/ja/user-guide/using_checkouts.txt
@@ -0,0 +1,97 @@
+チェックアウト機能を利用する
+============================
+
+ブランチをチェックアウトに変更する
+-----------------------------------
+
+ローカルのブランチを作りチェックアウトに変更したいのであれば、
+``bind`` コマンドを使います::
+
+ bzr bind bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+たとえば以前のセクションで説明されたように ``push`` を使って集中型の\
+ブランチを作った後でこれは必要です。
+
+これをした後は、コミットはローカルに適用される前にバインドした\
+ブランチに適用されます。
+
+チェックアウトをブランチに変更する
+----------------------------------
+
+チェックアウトを通常のブランチに変更したい場合、 ``unbind``
+コマンドを使います::
+
+ bzr unbind
+
+この後で、コミットはローカルのみに適用されます。
+
+チェックアウトを入手する
+-------------------------
+
+集中型のブランチを利用してチームで作業するとき、1人の人物が以前の\
+セクションで示される初期の内容を提供する必要があります。
+その後は、それぞれの個人が ローカルのチェックアウト、すなわち\
+彼らが変更を行うサンドボックス、を作るために ``checkout``
+コマンドを使用します。
+
+SubversionとCVSと異なり、Bazaarでは ``checkout`` コマンドは最新の内容を\
+保持している作業ツリーを作るのに加えて履歴のローカルな全コピーを作ります。
+``diff`` や ``log`` といったオペレーションは速く中心位置から接続していない\
+ときも利用できることを意味します。
+
+.. _getting-a-lightweight-checkout:
+
+軽量チェックアウトを入手する
+-----------------------------
+
+Bazaarはバージョン履歴を効率的に保存するために役立つ一方で、\
+履歴が望まれていないときがあります。
+たとえば、チームがBazaarを利用して集中型でウェブサイトの内容を\
+管理している場合、公開ウェブサーバー上の内容のチェックアウトを\
+更新するのと同じぐらいリリースプロセスは単純です。
+この場合、次の理由からその場所にダウンロードする履歴は望まないでしょう:
+
+ * 必要のない履歴を保有することでディスクスペースを無駄遣いする
+ * 秘密を維持したいBazaarブランチを公開する
+
+Bazaarで履歴のないチェックアウトを入手するには、
+``--lightweight`` オプションを使います::
+
+ bzr checkout --lightweight bzr+ssh://centralhost/srv/bzr/PROJECT/trunk
+
+もちろん、これによって通常のチェックアウトの多くの利点は失われますが、
+役に立つ場合と時を選ぶトレードオフです。
+``--lightweight`` オプションは、すべてのブランチではなくチェックアウト\
+のみに適用されます。
+
+注: コードベースが実際に大きくコンピュータ上のディスクスペースが限られている場合、
+`共用リポジトリ <branching_a_project.html#a-reminder-about-shared-repositories>`_,
+`スタックブランチ <stacked.html>`_,
+`チェックアウトを再利用する <reusing_a_checkout.html>`_
+を含めたすべてのオプションを必ず考えてください。
+
+
+最新の内容に更新する
+---------------------
+
+ロックステップでの他の人との連携の重要な面の1つはあなたのチェックアウトを\
+集中型のブランチで行われた最新の変更に更新し続けることです。
+SubversionもしくはCVSで行うように、Bazaarでは ``update`` コマンドを使用して\
+次のように行います::
+
+ bzr update
+
+ブランチに結びつけられたブランチで利用可能な新しいリビジョンを入手して\
+もしあればローカルの変更をマージします。
+
+コミットの失敗を扱う
+---------------------
+
+``commit`` を実行する前にチェックアウトを最新にしなければならないことに注意してください。
+Bazaarはこの点でSubversionもしくはCVSよりも厳密です - 変更したファイルだけでなく\
+すべてのツリーを最新にする必要があります。
+Bazaarはあなたが最後に更新した後で中心位置にリビジョンが追加されたことを検出すると
+``update`` を実行するようにあなたに頼みます。
+
+バインドされたブランチへのネットワーク接続が失われると、コミットは失敗します。
+いくつかの代替の次善策は次のセクションで説明します。
diff --git a/doc/ja/user-guide/using_gatekeepers.txt b/doc/ja/user-guide/using_gatekeepers.txt
new file mode 100644
index 0000000..ff089df
--- /dev/null
+++ b/doc/ja/user-guide/using_gatekeepers.txt
@@ -0,0 +1,42 @@
+ゲートキーパーを利用する
+=========================
+
+分散型の人間のゲートキーパーのワークフロー
+-------------------------------------------
+
+このワークフローでは、1人の開発者(ゲートキーパー) がメインブランチへの\
+コミット権限を持つ一方で他の開発者はリードオンリーの権限のみを持ちます。
+すべての開発者はタスクブランチの中で変更を行います。
+
+.. image:: images/workflows_gatekeeper.png
+
+開発者は彼らの作業内容をマージしたいとき、ゲートキーパーに彼らの変更を\
+レビューして受け入れ可能であればマージするよう頼みます。
+変更がレビューを失敗するとき、準備ができるまで関連のタスクブランチで\
+さらなる開発が進みます。
+
+このアプローチの主要な面は含まれる制御の反転です:
+開発者は変更を中心ブランチに"コミット/プッシュ"するときを決めなくて済みます:
+コードベースはゲートキーパーの "マージ/プル" による統制された変更方法によって発展します。
+複数の中心ブランチとそれぞれ異なるゲートキーパーをを持つことはとてもよい方法で、
+よく採用されている方法です。。
+たとえば、現在の製品リリースと次のリリースのためにそれぞれ1つづつのブランチがあります。
+この場合、たいがいはバグ修正を保持するタスクブランチは両方のゲートキーパーによって\
+通知されます。
+
+このワークフローのすばらしい点の一つはスケーラブルであることです。
+大きなプロジェクトはチームになりそれぞれのチームはゲートキーパーによって管理される
+*ローカルマスターブランチ* を持つことができます。
+チームリーダーがリクエストするときにチームのマスターブランチからの変更を\
+プライマリマスターブランチにマージするために誰かを主席ゲートキーパーに任命できます。
+
+分散型の自動ゲートキーパーのワークフロー
+-----------------------------------------
+
+より高い品質を得るために、すべての開発者は変更を回帰テストスイートが通ったら\
+変更のマージとコミットだけを行う自動ゲートキーパーに投稿できることが求められます。
+このようなゲートキーパーの1つはPQMと呼ばれるソフトウェアツールです。
+
+.. image:: images/workflows_pqm.png
+
+PQMに関する詳細な情報に関しては、 https://launchpad.net/pqm を参照してください。
diff --git a/doc/ja/user-guide/version_info.txt b/doc/ja/user-guide/version_info.txt
new file mode 100644
index 0000000..64cd51e
--- /dev/null
+++ b/doc/ja/user-guide/version_info.txt
@@ -0,0 +1,97 @@
+バージョンの情報をエクスポートする
+==================================
+
+最新のリビジョン番号を得る
+--------------------------
+
+ビルドスクリプトの中で最新のリビジョン番号だけが必要な場合、 ``revno`` コマンドを使用できます::
+
+ $ bzr revno
+ 3104
+
+
+詳細なバージョン情報を得る
+---------------------------
+
+最新バージョンに関する詳細な情報を出力するには ``version-info`` コマンドを使用できます::
+
+ $ bzr version-info
+ revision-id: pqm@pqm.ubuntu.com-20071211175118-s94sizduj201hrs5
+ date: 2007-12-11 17:51:18 +0000
+ build-date: 2007-12-13 13:14:51 +1000
+ revno: 3104
+ branch-nick: bzr.dev
+
+オペレーティングシステムツールもしくはスクリプトを使用して出力を簡単にフィルタリングできます。
+例です::
+
+ $ bzr version-info | grep ^date
+ date: 2007-12-11 17:51:18 +0000
+
+より高度な後処理のためにすべてのリビジョンに関するバージョン情報が必要であれば、
+``--all`` オプションはその情報を実際にダンプします。
+
+
+Pythonのプロジェクト
+--------------------
+
+.. TODO: Figure out how to attach into ``setup.py``
+
+
+プロジェクトファイルをビルドするためにMakefileを使う場合、
+次のようにバージョン情報用のファイルを簡単に生成できます::
+
+ library/_version.py:
+ bzr version-info --format python > library/_version.py
+
+これは3つのディレクトリを含むファイルを生成します:
+
+ * `version_info`: 現在の状態に関する基本情報を含むディレクトリ。
+
+ * `revisions`: コミット時間とコミットメッセージと一緒に、
+ ツリーの履歴の中のすべてのリビジョンのリストを表示するディクショナリ。
+ ``--all`` もしくは ``--include-history`` が提供されない限り、デフォルトではこれは空です。
+ リリースバージョンに含まれる、バグ修正などを追跡したい場合に便利です。
+ しかし多くのプロジェクトに対してこれは必要以上の情報です。
+
+ * `file_revisions`: プロジェクトのすべてのファイルに対する最終修正のリビジョンのリストを示すディクショナリ。
+ これは ``$Id$`` キーワードがCVSで管理されたファイルと同じように使われます。
+ 最終修正の日付は ``revisions`` マップで探すことで決定されます。
+ デフォルトではこれは空で、 ``--all`` もしくは ``--include-file-revisions`` によってのみ有効になります
+
+
+別のフォーマットでバージョン情報を得る
+--------------------------------------
+
+任意のフォーマットのバージョン情報を取得するためにBazaarはテンプレートベースの方法をサポートします。
+``version-info`` への ``--custom`` オプションは作業ツリーのステータスに基づいて拡張された変数を含む
+``--template`` 引数を提供することで使用できます。
+
+たとえば、現在のリビジョン番号を含むフォーマットされた文字列を伴うCヘッダーファイルを生成するには::
+
+ bzr version-info --custom \
+ --template="#define VERSION_INFO \"Project 1.2.3 (r{revno})\"\n" \
+ > version_info.h
+
+``{revno}`` は作業ツリーのリビジョン番号に置き換えされます。
+(上記の例があなたのOSで動作しない場合、一行ですべてのコマンドを入力してみてください)
+テンプレートの中で利用できる変数の詳細な情報に関しては、
+Bazaarのユーザーリファレンスの `Version Info`_ を参照してください。
+
+.. _Version Info: ../user-reference/index.html#version-info
+
+特定の言語でバージョン情報をダンプするために予め定義されるフォーマットはは現在開発段階にあります。
+この領域の要求に関してはメーリングリストで私達開発者に連絡して下さるようお願いします。
+
+チェッククリーン
+-----------------
+
+プロジェクトの内容に関する大抵の情報はリビジョンエントリを読むだけで簡単に決定できます。
+しかしながら、作業ツリーがパッケージされたときにそれが最新であったこと、
+もしくはローカルな修正があったことを知るためには便利です。
+``--all`` もしくは ``--check-clean`` のどちらかを提供することで ``bzr`` は作業ツリーを検査して、
+``version_info`` ``clean`` を設定します。
+同様に ``modified`` が適切である場合に ``file_revisions`` でエントリを設定します。
+
+..
+ vim: tw=74 ft=rst spell spelllang=en_us
diff --git a/doc/ja/user-guide/web_browsing.txt b/doc/ja/user-guide/web_browsing.txt
new file mode 100644
index 0000000..d2c7662
--- /dev/null
+++ b/doc/ja/user-guide/web_browsing.txt
@@ -0,0 +1,16 @@
+ウェブブラウジング
+==================
+
+概要
+-----
+
+BazaarのリポジトリをWeb上で閲覧するために利用できる選択肢は幅広くあり、\
+主要なものは Loggerhead です。
+Loggerhead のホームページは https://launchpad.net/loggerhead にあります。
+
+ダウンロードリンクを含めてこれらのパッケージの最新情報に関しては
+http://wiki.bazaar.canonical.com/WebInterface
+を参照してください。
+
+注: プロジェクトがホストされているもしくはLaunchpadでミラーリングされている場合、
+Loggerheadのコードブラウジング機能はサービスの一部として提供されます。
diff --git a/doc/ja/user-guide/working_offline_central.txt b/doc/ja/user-guide/working_offline_central.txt
new file mode 100644
index 0000000..5e0a558
--- /dev/null
+++ b/doc/ja/user-guide/working_offline_central.txt
@@ -0,0 +1,50 @@
+オフラインで集中型のブランチに取り組む
+=======================================
+
+集中型のローカルコミットのワークフロー
+---------------------------------------
+
+旅行のためネットワーク接続できない場合、中心サーバーがダウンする、\
+もしくは今は中心位置に公開せずにローカルで変更のスナップショットを\
+記録したいだけなら、このワークフローはそんなあなたのためにあります。
+
+.. image:: images/workflows_localcommit.png
+
+ローカルでコミットする
+-----------------------
+
+チェックアウトで作業していてローカルだけでコミットする必要がある/したい場合、
+``--local`` オプションを ``commit`` コマンドに追加します::
+
+ bzr commit --local
+
+長期間切断する
+---------------
+
+しばらくの間バインドされたブランチから切断をする予定もしくはしたい場合、
+``--local`` をすべての ``commit`` コマンドを追加することを覚えるのは面倒でしょう。
+代わりの方法は チェックアウトを一時的に通常のブランチにするために ``unbind``
+コマンドを用い、後でロックステップの状態に戻りたくなったときに ``bind`` コマンド\
+を使うことです。
+
+``bind`` コマンドはこのブランチがチェックアウトされた最後の時間が結びつけられた\
+場所を覚えるので、前の ``unbind`` の後で ``bind`` を使うときにリモートブランチの\
+URLを入力する必要がないことに留意してください。
+
+ローカルコミットのシリーズをマージする
+---------------------------------------
+
+中心ブランチ上で進行中の開発から独立してローカルでコミットするとき、\
+次回 ``update`` が実行されるときBazaarはこれらを開発の2つのラインとして扱います。
+この場合、 ``update`` は次のことを行います:
+
+ * これはバインドされたブランチからの最新のリビジョンを取り込み、チェックアウトを\
+ メインラインの状態にします。
+
+ * これは最後に更新した以降のローカルな変更を論理的に並行ブランチに移動します
+
+ * これらを一緒にマージするのでローカルの変更は ``status`` によって未解決マージ
+ として報告されます
+
+常に、この後で作業内容を中心ブランチに送信するためには ``commit`` を実行する\
+必要があります。
diff --git a/doc/ja/user-guide/writing_a_plugin.txt b/doc/ja/user-guide/writing_a_plugin.txt
new file mode 100644
index 0000000..f860e46
--- /dev/null
+++ b/doc/ja/user-guide/writing_a_plugin.txt
@@ -0,0 +1,74 @@
+.. _writing-a-plugin:
+
+プラグインを書く
+================
+
+導入
+-----
+
+プラグインはbzrのコア機能ととてもよく似ています。
+これらはbzrlibから何でもインポートできます。
+プラグインは標準機能を上書きすることもできますが、大抵プラグインは\
+新しいコマンドを提供します。
+
+.. _creating-a-new-command:
+
+新しいコマンドを作る
+---------------------
+
+コマンドを書くには、
+``bzrlib.commands.Command`` を継承する新しいオブジェクトを作り、 ``cmd_foo`` と命名します。
+fooはコマンドの名前です。
+名前にアンダースコアが含まれるコマンドを作ると、UIではアンダースコアはハイフンとして表示されます。
+たとえば、 `cmd_baz_import` は `baz-import` として表示されます。
+コマンドの書き方の実例に関しては、 ``builtins.py`` を参照して頂くようお願いします。
+
+コマンドを作成したらファイルがインポートされるときに
+``bzrlib.commands.register_command(cmd_foo)`` でコマンドを登録しなければなりません。
+さもなければbzrはコマンドを見つけることはありません。
+
+.. _installing-a-hook:
+
+フックをインストールする
+-------------------------
+
+`Using hooks`_ を参照してください。
+
+.. _Using hooks: hooks.txt
+
+
+.. _specifying-a-plugin-version-number:
+
+プラグインのバージョン番号を指定する
+-------------------------------------
+
+プラグインのバージョン番号を定義するにはタプルで ``version_info`` を定義します。例:
+``version_info = (0, 9, 0)``
+``version_info = (0, 9, 0, 'dev', 0)``
+
+.. _plugin-searching-rules:
+
+プラグインの検索ルール
+------------------------
+
+デフォルトではbzrはプラグインを見つけるために ``~/.bazaar/plugins`` と
+``bzrlib/plugins`` をスキャンします。
+``BZR_PLUGIN_PATH`` でこれを上書きできます。
+(詳細は、
+`ユーザーリファレンス <../user-reference/configuration-help.html#bzr-plugin-path>`_
+を参照してください。)
+
+プラグインはモジュールもしくはパッケージの形態をとることができます。
+プラグインが単独のファイルであれば、構造をモジュールにできます。
+プラグインが複数のファイルを持つ場合やbzrのブランチとして配布したい場合は、
+構造をパッケージ、すなわち、ディレクトリの中に ``__init__.py`` を含めます。
+
+
+詳しい情報
+-----------
+
+他の人にも役立つと考えましたら、プラグインをBzrToolsにお気軽に寄付してください。
+
+Bazaarの開発ガイドラインと方針の詳細に関しては `Bazaar開発者ガイド`_ を参照してください。
+
+.. _Bazaar開発者ガイド: ../developer-guide/HACKING.html
diff --git a/doc/ja/user-guide/zen.txt b/doc/ja/user-guide/zen.txt
new file mode 100644
index 0000000..7536b69
--- /dev/null
+++ b/doc/ja/user-guide/zen.txt
@@ -0,0 +1,195 @@
+Bazaarの哲学
+============
+
+Bazaarを完全に理解する
+-----------------------
+
+Bazaarは多くの点で他のVCSに似ていますが、最初見たときに必ずしも明らかではない大きな違いがいくつかあります。
+このセクションでは Bazaarを"grok"するため、すなわち深く理解するために、
+ユーザーが知る必要のあるいくつかの内容の説明を試みます。
+
+注: Bazaarを使うためにこのセクションを十分に理解する必要はありません。
+このセクションをさっと読んで後で戻るとよいでしょう。
+
+リビジョン番号を理解する
+------------------------
+
+ブランチのメインラインのすべてのリビジョンは単純に増加する整数を持ちます(最初のコミットは1、10番目のコミットは10などです)。
+これによって "私のブランチから10番目のリビジョンを獲得する"、もしくは "リビジョン3050で修正した" という言い方が自然になります。
+
+ブランチにマージされるリビジョンに関しては、ドットつきのバージョンが使われます(たとえば、3112.1.5)。
+ドットつきのリビジョン番号は3つの番号を持ちます [#]_.
+最初の番号はメインのリビジョンの変更の由来を示します。
+2番目の番号はブランチのカウンターです。
+同じリビジョンから多くのブランチが由来することがあり得るので、それらのブランチはユニークな番号を取得します。
+3番目の番号はブランチの開始以降のリビジョン番号です。
+たとえば、3112.1.5はリビジョン3112からの最初のブランチで、そのブランチ上の5番目のリビジョンです。
+
+.. [#] バージョン1.2以前のbzrでは少し異なるアルゴリズムが使われていました。
+ いくつかの入れ子のブランチはよりシンプルな3つの番号システムではなく追加の番号(たとえば1.1.1.1.1)を取得します。
+
+階層形式の履歴はよいものである
+-------------------------------
+
+多くの変更が一連のコミットで構成される状況で複数の開発者が変更を投稿するプロジェクトを想像してください。
+具体例を示すために、次の事例を考えてみましょう:
+
+ * プロジェクトのトランクのチップはリビジョン100です。
+ * Maryは機能Xを配信するために3つの変更を行う
+ * Billは機能Yを配信するために4つの変更を行う
+
+開発者が並行して作業して伝統的な集中型のVCSのアプローチを利用する場合、
+大抵の場合プロジェクトの履歴は次のようにMaryの変更とBillの変更が交互に混ざります::
+
+ 107: Add documentation for Y
+ 106: Fix bug found in testing Y
+ 105: Fix bug found in testing X
+ 104: Add code for Y
+ 103: Add documentation for X
+ 102: Add code and tests for X
+ 101: Add tests for Y
+ 100: ...
+
+多くのチームはこのアプローチを利用します。彼らのツールではブランチの作成とマージが難しいからです。
+結果として、開発者はトランクからの更新とコミットを頻繁に行い、すべてのコミットを通してそれを広げることで統合の苦痛を最小化します。
+望むのであれば、このようにBazaarを使うことができます。
+Bazaarは考慮すべき別の方法を提供します。
+
+分散型のVCSツールによって推奨される代替のアプローチは機能ブランチを作り、準備ができたらそれらを統合することです。
+この場合、Maryの機能ブランチは次のようになります::
+
+ 103: Fix bug found in testing X
+ 102: Add documentation for X
+ 101: Add code and tests for X
+ 100: ...
+
+そしてBillのものは次のようになります::
+
+ 104: Add documentation for Y
+ 103: Fix bug found in testing Y
+ 102: Add code for Y
+ 101: Add tests for Y
+ 100: ...
+
+機能が独立していてリニアな履歴を維持したいのであれば、変更はバッチでトランクにpushされます。
+(技術的には、これを行う方法は無数にありますがこの検討内容の範囲を超えます。)
+結果の履歴は次のようになります::
+
+ 107: Fix bug found in testing X
+ 106: Add documentation for X
+ 105: Add code and tests for X
+ 104: Add documentation for Y
+ 103: Fix bug found in testing Y
+ 102: Add code for Y
+ 101: Add tests for Y
+ 100: ...
+
+これを実現するために少し努力が必要な一方で、リビジョンをランダムに織り交ぜるよりもいくつかの利点があります。
+よりベターですが、non-linearな履歴を形成してブランチは一緒にマージできます。
+結果は次のようになります::
+
+ 102: Merge feature X
+ 100.2.3: Fix bug found in testing X
+ 100.2.2: Add documentation for X
+ 100.2.1: Add code and tests for X
+ 101: Merge feature Y
+ 100.1.4: Add documentation for Y
+ 100.1.3: Fix bug found in testing Y
+ 100.1.2: Add code for Y
+ 100.1.1: Add tests for Y
+ 100: ...
+
+もしくは次のようになります::
+
+ 102: Merge feature X
+ 100.2.3: Fix bug
+ 100.2.2: Add documentation
+ 100.2.1: Add code and tests
+ 101: Merge feature Y
+ 100.1.4: Add documentation
+ 100.1.3: Fix bug found in testing
+ 100.1.2: Add code
+ 100.1.1: Add tests
+ 100: ...
+
+多くの理由からこれはよいものと考えられます:
+
+ * プロジェクトの履歴を理解するのが楽になります。
+ 関連した変更はクラスターを形成し明確に区切られます。
+
+ * ブランチのメインライン上のコミットだけを見るために履歴を簡単に折りたたむことができます。
+ (このレベルでは興味のない膨大な数のコミットの代わりに)
+ このようなトランクの履歴を閲覧するとき、高いレベルのコミットだけ見えます。
+
+ * 必要であれば、より簡単に機能の変更を取り消します
+
+ * 継続的インテグレーション(Continuous integration: CI)ツールは
+ マージをメインラインにコミットするためにすべてのテストが合格することを保証するために使われます。
+ (多くの場合、すべての単独のコミットの後でCIツールの引き金を引くのは適切ではありません。
+ テストの中には開発の間に失敗するものがあるからです。
+ 実際、テストファーストの追加 - テスト駆動開発(TDD)のスタイル - によってこれが保証されます!)
+
+要約すると、重要な点は次のとおりです:
+
+ *ブランチを利用してあなたの作業内容を編成する*
+
+ *マージ機能を利用して変更を統合する*
+
+ *順序つきの番号と階層によって履歴を追跡するのが楽になる*
+
+
+それぞれのブランチは履歴の独自のビューを持つ
+---------------------------------------------
+
+上述のように、Bazaarは次の内容を区別します:
+
+ * メインラインのリビジョン、すなわちブランチにコミットしたもの
+
+ * マージしたリビジョン、マージをコミットすることで祖先として追加されるもの
+
+それぞれのブランチは効率的に履歴の独自ビューを持ち、すなわち、
+異なるブランチは同じリビジョンに異なる"ローカルな"リビジョン番号を与えます。
+
+マージされたリビジョンは常にドットつきのリビジョン番号を入手するのに対して
+メインラインのリビジョンは常に単独の数字のリビジョン番号が割り当てられます。
+
+上記の例を拡張するためには、Maryが変更を完了させた後でプロジェクトのトランクにマージした後に
+Maryのブランチのリビジョンの履歴は次のようになります::
+
+ 104: Merge mainline
+ 100.2.1: Merge feature Y
+ 100.1.4: Add documentation
+ 100.1.3: Fix bug found in testing
+ 100.1.2: Add code
+ 100.1.1: Add tests
+ 103: Fix bug found in testing X
+ 102: Add documentation for X
+ 101: Add code and tests for X
+ 100: ...
+
+繰り返しますが、Maryはこの変更を開発するためにステップを見るために彼女の履歴のトップレベルを調べることが簡単になります。
+この文脈では、トランクのマージ(とそれを行うことによる衝突の解消)はこのブランチの履歴に関しては単なる1つのステップです。
+
+Bazaarは履歴を変更するのでなければグローバルなリビジョン識別子を変更するのでもないことを覚えておくのは大事です。
+本当に望むのであれば常に後者を使用できます。
+実際、ブランチのURLをコンテクストとして提供する *限り* コミュニケーションをするときに特定のリビジョン番号を使うことができます。
+(多くのBazaarのプロジェクトでは、開発者はブランチURLなしでリビジョン番号を交換するとき中心のトランクのブランチをほのめかします)
+
+マージはブランチのリビジョン番号を変更しません。それらはローカルのリビジョン番号を新しくマージしたリビジョンに割り当てるからです。
+Bazaarがブランチのリビジョン番号を変更する唯一のときはあなたが明示的に別のブランチをミラーリングするように頼むときです。
+
+注: リビジョンは安定した方法で番号づけされます: 2つのブランチがメインラインで同じリビジョン番号を持つとき、
+そのリビジョンの祖先のすべてのリビジョンは同じリビジョン番号を持ちます。
+たとえば、AliceとBobのブランチがリビジョン10に一致するのであれば、それらはそれ以前のすべてのリビジョンで一致します。
+
+要約
+-----
+
+一般的に、前に示されたアドバイスに従うのであれば - ブランチの中で作業し、\
+連携するためにマージを使う -
+Bazaarが一般的にあなたが期待することを行うことがわかります。
+
+次の章では、Bazaarを利用したさまざまな方法: もっとも単純なプロジェクト、個人プロジェクトなどを試します。
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/ja/user-reference/index.txt b/doc/ja/user-reference/index.txt
new file mode 100644
index 0000000..8b4ed70
--- /dev/null
+++ b/doc/ja/user-reference/index.txt
@@ -0,0 +1,3855 @@
+.. This file is autogenerated from the output of
+.. bzr help topics
+.. bzr help commands
+.. bzr help <cmd>
+..
+.. Generation time: 2009-01-09 07:03:09 +0000
+
+##########################
+Bazaarユーザーリファレンス
+##########################
+
+:Version: 1.11
+:Generated: 2009-01-09
+
+.. contents:: :depth: 2
+
+-----
+
+このチュートリアルについて
+##########################
+
+このマニュアルはBazaarのオンラインヘルプから生成されました。オンラインヘルプのシステムを
+利用するためには次のコマンドを試してください。
+
+ よく使われるコマンドの一覧を含めて紹介します::
+
+ bzr help
+
+ トピックの一覧とそれぞれの要約::
+
+ bzr help topics
+
+ コマンドの一覧とそれぞれの要約::
+
+ bzr help commands
+
+ 特定のトピックもしくはコマンドに関する詳細な情報::
+
+ bzr help topic-or-command-name
+
+次のウェブサイトはBazaarに関する詳細な情報を提供します:
+
+:ホームページ: http://www.bazaar-vcs.org/
+:公式ドキュメント: http://doc.bazaar-vcs.org/
+:Launchpad: https://launchpad.net/bzr/
+
+概念
+####
+
+ブランチ
+=========
+
+ブランチは、すべての履歴を含む、プロジェクトの状態で構成されます。
+すべてのブランチは関連づけされたリポジトリ(ブランチの履歴が保存される場所)を持ちますが、
+複数のブランチは同じリポジトリを共有することもあります(共用リポジトリ)。
+ブランチはコピーしたりマージしたりできます。
+
+関連コマンド::
+
+ init ディレクトリをバージョン管理されたブランチに変更する。
+ branch ブランチの新しいコピーを作成する。
+ merge 3方向マージ (3-way merge) を実行する。
+
+
+チェックアウト
+==============
+
+チェックアウトはブランチに結びつけられたソースツリーなので、
+ソースツリーにコミットするときに、コミットの内容はブランチに格納されます。
+必要になるまでBazaarの分散型機能の一部を無視して、よりシンプルに、集中型のワークフローを利用できます。
+共用リポジトリでチェックアウトを利用することはSVNもしくはCVSでの作業とよく似ていますが、同じ制限を持ちません。
+そしてチェックアウトを利用することで望むワークフローがなんであれ他の人もプロジェクトに取り組むことができます。
+
+チェックアウトはbzr checkoutコマンド("help checkout"を参照)によって作成されます。
+これに別のブランチへのリファレンスを渡し、マスターブランチからのチェックアウトを作成したブランチへのリファレンスを
+まだ含むローカルコピーを作成します。
+
+何かコミットをすればこれらは他のブランチで最初に作成されます。
+これによって作業内容のインスタントミラーが作成されるもしくは
+それぞれの開発者が共同で作業して他の人の変更を継続的に統合するロックステップ開発を円滑にします。
+
+しかしながらチェックアウトはまだBazaarの第一級のブランチで、すべての履歴をローカルで保存できます。
+第一級のブランチがあるので、ローカルにコミットすることもできます。
+たとえば、ネットワーク接続による一時的な遅延を回避したいのであれば、ローカルでもコミットできます。
+これを行うには --local オプションを使います。
+次にローカルではないコミットを行うときにすべてのローカルコミットはマスターブランチに行われます。
+
+共用ブランチからのチェックアウトを使用しているとき、周期的に他の人による変更をすべてpullしたくなります。
+これは"update"コマンドによってできます。
+ローカルではないコミットの前に変更が適用される必要がありますが、
+Bazaarは変更が存在することを伝え必要なときにこのコマンドを使うように提示します。
+
+checkoutコマンドに--lightweightフラグを渡すことで"軽量"チェックアウトを作成することも可能です。
+第一級のブランチではなく、主に作業ツリーで構成されるという点で、軽量チェックアウトはSVNのチェックアウトにより近いです。
+履歴のオペレーションはマスターブランチに問い合わせをしなければならないので、
+ネットワーク接続が関わる場合遅くなる可能性があることを意味します。
+また、ローカルブランチを持たないので、ローカルでコミットできません。
+
+マスターブランチに高速で信頼性のあるアクセス権限があるときに軽量チェックアウトは最も良く動作します。
+マスターブランチが同じディスクもしくはLAN上にあれば、(ブランチのコピーの更新だけが必要なので)
+リビジョンを変更するどのコマンドでも軽量ブランチは重量ブランチよりも速くなることを意味します。
+一般的に重量チェックアウトは速いですが、マスターブランチが同じディスク上のあるときは、顕著な違いはありません。
+
+チェックアウトの別の使い方はブランチを格納するツリーなしのリポジトリで使うことです。
+ここでは異なるブランチに取り組むときチェックアウトが指定するマスターブランチを切り替えることで
+1つの作業ツリーだけを維持します。
+
+明確にチェックアウトにコミットするにはマスターブランチへの書き込み権限が必要です。
+マスターブランチはsftp://といった書き込み可能なプロトコルでアクセスしなければならないので、
+相手方で書き込み権限をもたなければならないことを意味します。
+チェックアウトはローカルファイルシステムでも機能するので、すべての問題はファイルのパーミッションです。
+
+"bind"コマンド("help bind"を参照)を使用することでチェックアウトのマスターを変更できます。
+これによってコミットが送信される位置が変更されます。
+bindコマンドはブランチをheavyチェックアウトに変換するためにも使用できます。
+すべてのコミットがローカルで行われるようにheavyチェックアウトを通常のブランチに変換したい場合、
+"unbind" コマンドを使用できます。
+
+関連コマンド::
+
+ checkout チェックアウトを作成する。軽量チェックアウトを得るには --lightweight を渡す
+ update マスターブランチの変更をあなたのチェックアウトにpullする
+ commit マスターブランチに送信されるコミットを行う。
+ 重量チェックアウトであれば --localオプションによって
+ マスターにコミットを送信せずにチェックアウトにコミットされます
+ bind 送信されるチェックアウトにコミットされるマスターブランチを変更する
+ unbind コミットがローカルだけで行われるように重量チェックアウトをスタンドアロンのブランチに変換する
+
+
+クリスクロス
+============
+
+ブランチの履歴のクリスクロス(Criss-cross)は通常期待されるよりも多くのコンフリクトを出すデフォルトのマージテクニックを必要とします。
+
+複雑なマージの場合、 ``bzr merge --lca`` もしくは ``bzr merge --weave`` ではよりよい結果になるかもしれません。
+作業ツリーを ``bzr revert`` して再度マージしたいと願うかもしれません。
+代わりに、特定の衝突しているファイル上で ``bzr remerge`` を使います。
+
+2つのブランチが同じものをマージしてお互いにマージし合う場合、
+もしくは2つのブランチが同時にお互いをマージする場合、クリスクロスはブランチの中で発生します。
+それぞれのブランチが目的の集中型ブランチからもしくはそのブランチからのみマージすることでこれらを回避できます("star topology")。
+
+マージが動作する方法のためクリスクロスは問題を引き起こします。
+Bazaarのデフォルトマージは三方向マージです; OTHERをTHISにマージするには比較、BASE用の基本を見つけなければなりません。
+BASEを利用することで、THISとOTHERの違いが行を追加するワンサイドか、行を削除する別のサイドによるのかを決定できます。
+
+クリスクロスはベースに関してよい選択肢がないことを意味します。
+最近のマージポイントを選択することはワンサイドの変更を少し廃棄してしまう可能性があります。
+(Bazaarが行う)古いマージポイントを選択することは余分な衝突が発せられることを意味します。
+
+``weave`` マージタイプはこの問題の影響を受けません。
+このタイプは違いの原因を決定するためにベースのリビジョンの代わりに行を起点とする検出方法を利用するからです。
+
+
+ストレージフォーマット
+=======================
+
+古いクライアントが不正にデータにアクセスしないことを保証するために、
+Bazaarのポリシーでは新しい機能が新しいメタデータを追加する必要があるときに
+新しいフォーマットを導入することにしています。新しいストレージフォーマットは
+パフォーマンスとスケーラビリティを改善するために導入することもあります。
+
+フォーマットを選ぶために次のガイドラインを利用します(条件がtrueであると同時に停止):
+
+* 既存のプロジェクトに取り組んでいる場合、プロジェクトが利用しているものを使用します。
+ (デフォルトでBazaarはあなたの代わりにこれを行います)。
+
+* Subversionリポジトリと連携するbzr-svnを利用している場合は、
+ 1.9-rich-rootを使用します。
+
+* 大きなツリー(5000以上のパス)もしくは深い履歴(5000以上のリビジョン)を持つ
+ プロジェクトに取り組んでいるのであれば、1.9を使用します。
+
+* さもなければ、デフォルトのフォーマットを使用します。大抵のプロジェクトはこれで十分です。
+
+(ディストロのパッケージを利用しているなどで)最新のBazaarを利用できない開発者がいるのであれば、
+それに応じてガイドラインを調整してください。
+たとえば、プロジェクトがBazaar 1.7を標準化している場合、1.9の代わりに1.6を選ぶことが必要です。
+
+注: 現在サポートされるフォーマットの多くは2つのバリアントを持ちます:
+plainのものとrich-rootのものです。
+後者はツリーのrootに関する追加フィールドを含みます。
+rich-rootフォーマットを利用する際にパフォーマンスコストはありませんが
+rich-rootフォーマットからの変更をplainフォーマットに簡単にマージできません。
+結果として、すべての投稿者がほぼ同時にリポジトリをアップグレードする必要があるので、
+プロジェクトをrich-rootフォーマットに移行させるには調整が必要です。
+(これまでのところrich-rootフォーマットをデフォルトにすることを遅らせてきた理由です。
+将来の適切な時期にこれを行います。)
+
+現在サポートされるフォーマットの完全なリストに関しては ``bzr help current-formats`` を参照してください。
+利用可能で実験上もしくは廃止されたフォーマットに関しては ``bzr help other-formats`` を参照してください。
+
+
+パターン
+========
+
+Bazaarはさまざまな時点でマッチするファイルを使用します。
+たとえば、 ``add`` コマンドは無視するパターンにマッチするファイルとスキップし
+プリファレンスはルールパターンを使用するファイルに関連づけできます。
+パターン構文は下記のとおりです。
+
+パターン上のトレーリングスラッシュは無視されます。
+パターンがスラッシュを含むもしくは正規表現である場合、ブランチのroot全体から比較されます。
+さもなければ、これはパスの最後のコンポーネントのみと比較されます。
+rootディレクトリの中のファイルのみにマッチさせるには'./'を用意します。
+絶対パスを指定するパターンは許可されていません。
+
+パターンは次のようなglobのワイルドカードを含むことができます::
+
+ ? - '/'以外の単独文字にマッチする
+ * - '/'以外の0かそれ以上の文字数にマッチする
+ /**/ - パスの中のゼロかそれ以上のディレクトリにマッチする
+ [a-z] - 文字のグループの範囲内からの単独の文字にマッチする
+
+パターンはPythonの正規表現にもなります。
+正規表現のパターンは 'RE:' の接頭辞で始まる正規表現で識別されます。
+正規表現のパターンは名前つきもしくは番号つきのグループを含むことはできません。
+
+
+リポジトリ
+===========
+
+Bazaarのリポジトリはコミットされた情報が保存される場所です。
+すべてのブランチと関連づけされたリポジトリが1つ存在します。
+
+リポジトリは一種のデータベースです。
+通常、パフォーマンスのためにBzrはこれを自動的に維持しますが、ある状況(たとえば短い期間にとても多くのコミットを行う)
+
+データベースのインデックスを最適化するようbzrに求めるとよいでしょう。
+これは'bzr pack' コマンドによって行われます。
+
+デフォルトでは 'bzr init' を実行するだけで新しいブランチの中でリポジトリが作成されますが、
+同じ位置で情報を共有するために複数のブランチを許可する共用リポジトリを作成することが可能です。
+新しいブランチが作成されたとき使用できる共用リポジトリが存在するかどうかを最初に確認します。
+
+同じプロジェクトのブランチが1つのリポジトリを共有するとき、一般的にスペースが大きく節約されます。
+(たとえばリポジトリの範囲内でブランチを作成するなどの)いくつかのコマンドに対してこれは大きな時間の節約になります。
+
+共用リポジトリを作るには、init-repositoryコマンド(もしくはエイリアスのinit-repo)を使います。
+このコマンドは作成するリポジトリの位置をとります。
+このことは'bzr init-repository repo'によって'repo'という名前のディレクトリが作成され
+その中に共用リポジトリが格納されることを意味します。
+このディレクトリの中に作成された新しいブランチはストレージ用にそれを使用します。
+
+1つ以上のプロジェクトのブランチを作成するときに1つのリポジトリを作成することはよい考えです。
+これは開発を行っている作業領域と、ホスティングプロジェクト用のサーバー領域の両方にあてはまります。
+後者の場合、作業ツリーなしのブランチが欲しいことは良くあります。
+ブランチのファイルは直接編集されないので作業ツリー用にディスクスペースを使い切る必要はありません。
+作業ブランチを持たないリポジトリを作成するには、 'init-repository'に'--no-trees'オプションを渡します。
+
+関連コマンド::
+
+ init-repository 共用リポジトリを作成する。
+ 新しいブランチが作業ツリーを作成しないものを作成するには--no-treesを使用する。
+
+
+ルール
+=======
+
+紹介
+-----
+
+ルールはiniファイルフォーマットで定義されます。
+セクションはファイルのglobパターンでそれぞれのセクションの内容は
+そのパターンにマッチするファイル用のプリファレンスです。例です::
+
+ [name *.bat]
+ eol = dos
+
+ [name *.html]
+ keywords = escape
+
+これらのようなプリファレンスは選択されたブランチの中で
+選択されたファイル用にカスタムのふるまいを提供したいコマンドとプラグインに役立ちます。
+
+
+ファイル
+---------
+
+すべてのブランチ用のデフォルトルールはオプションの ``BZR_HOME/rules`` ファイルで定義されます。
+
+ルールのパターン
+-----------------
+
+パターンは順序づけされ1つマッチすると共に検索は停止します。
+結果として、より明確なパターンをファイルのトップの方に置くべきです。
+ルールパターンは無視パターンとまったく同じ仕様を利用します。
+詳細は ``bzr help patterns`` を参照してください。
+
+注: 角かっこを含むパターンはそれらが正しく解析されるようにクォートで囲まなければなりません。
+
+
+スタンドアロンのツリー
+=======================
+
+スタンドアロンのツリーは関連リポジトリを持つ作業ツリーです。
+他に依存していないので、これは独立して利用できるブランチです。
+(bzr initを通して)スタンドアロンのツリーの作成は
+既存のプロジェクトをバージョン管理の元に置くための最も速い方法です。
+
+関連コマンド::
+
+ init ディレクトリをバージョン管理下にあるブランチにする。
+
+
+同期化がずれているブランチ
+==========================
+
+チェックアウト、ツリーもしくはブランチを軽量ブランチに再設定するとき、
+ローカルのブランチを破壊しなければなりません。
+(チェックアウトに関して、これはキャッシュとして最初に提供するローカルブランチです。)
+破壊されるブランチが同じ最終リビジョンを持たなければ、
+軽量用チェックアウト用の新しい参照ブランチ、データが失われる可能性があるので、
+Bazaarは拒否します。
+
+この取り組み方は *なぜ* ブランチの同期がずれるのかによります。
+
+チェックアウトが手元にありローカルコミットを行う場合、
+"bzr update"(とおそらくは"bzr commit")を実行することで再び同期化できます。
+
+ブランチが手元にあり、リモートブランチが時代遅れになっている場合、
+"bzr push"を使用してローカルの変更をプッシュできます。
+ローカルブランチが時代遅れであれば、"bzr pull"をできます。
+両方のブランチに変更があれば、変更をマージ、コミットしてプッシュできます。
+変更の一部が便利でなければ、"push --overwrite"もしくは代わりに"pull --overwrite"できます。
+
+
+作業ツリー
+===========
+
+作業ツリーはディスク上に設置されたブランチのコンテンツなのでファイルを見て編集できます。
+作業ツリーはブランチに変更を行う場所なので、
+作業ツリーの現在の状態をコミットするとき、コミットに記録されるレコードです。
+
+ブランチをリモートシステムにプッシュするとき、作業ツリーは作成されません。
+ファイルがすでに存在すれば、ファイルは更新されません。
+ブランチの情報は更新され作業ツリーは時代遅れとしてマークされます。
+リモートの作業ツリーを更新するのは難しいです。
+アンコミットされた変更が存在するもしくは更新によってリモートで扱うのが難しい内容の衝突が引き起こされるからです。
+
+作業ツリーなしのブランチがあれば 作業ツリーを作成するために 'checkout' コマンドを使用できます。
+ブランチから 'bzr checkout .' を実行すると作業ツリーが作成されます。
+リモートでブランチが更新されると、そのディレクトリの中で'bzr update'を実行することで作業ツリーを更新できます。
+
+望まない作業ツリーを持つブランチがある場合、安全であれば'remove-tree'コマンドはツリーを除外します。
+ブランチにプッシュするとき更新されないリモート作業ツリーに関する警告を回避することでこれは可能です。
+これは'--no-trees'リポジトリ('bzr help repositories'を参照)に取り組むときにも便利です。
+
+プッシュするリモートマシン上で作業ブランチを持ちたい場合、
+pushするごとにリモートブランチで'bzr update'を実行するか、
+pushの間にツリーを更新する他の方法を使用できます。
+rsyncを使用してpushと同じように作業ツリーを更新する'rspush'プラグインが存在します。
+それぞれのプッシュの後で'bzr update'を自動的に実行する'push-and-update'プラグインも存在します。
+
+便利なコマンド::
+
+ checkout ブランチが作業ツリーを持たないときにそれを作成する。
+ remove-tree これを行うときに安全であるときにブランチから作業ツリーを除外する。
+ update 作業ツリーが関連ブランチから同期がずれているとき
+ このコマンドによってブランチにマッチするツリーが更新される。
+
+.. _formats: `ストレージフォーマット`_
+.. _standalone-trees: `スタンドアロンのツリー`_
+.. _sync-for-reconfigure: `同期化がずれているブランチ`_
+.. _working-trees: `作業ツリー`_
+
+
+
+リスト
+#######
+
+認証の設定
+===========
+
+
+Intent
+------
+
+``authentication.conf`` ファイルの中で多くの異なる認証ポリシーは記述できますが
+特定のユーザーはすべてのブランチ用のユーザーとパスワードを指定しなくても
+自分のニーズをカバーするわずかな定義だけが必要です。
+
+このファイルの中で見つかる定義は与えられたurl用のクレデンシャルを見つけるために使われます。
+一般的に同じクレデンシャルを必要とするリモートサーバーの周辺で宣言を分類することで可能な限り多くのブランチに対して
+クレデンシャルを使用できます。
+
+異なるサーバーによって使用されるクレデンシャルを宣言することも可能です。
+
+intentは維持を最少にするためにこのファイルを可能な限り小さくするものです。
+
+このファイルの中で関連のクレデンシャルが宣言されるとパスワード(セキュリティハザード)を埋め込まず
+もしくは(他の人とURLの共有を有効にする)ユーザーなしでブランチのURLを利用できます。
+
+次のURLよりも::
+
+ bzr branch ftp://joe:secret@host.com/path/to/my/branch
+
+シンプルになります::
+
+ bzr branch ftp://host.com/path/to/my/branch
+
+``authentication.conf`` ファイルを作成したことを前提とします::
+
+ [myprojects]
+ scheme=ftp
+ host=host.com
+ user=joe
+ password=secret
+
+
+認証の定義
+-----------
+
+bzrによってサポートされるさまざまなスキームによって使用される2種類の認証があります:
+
+1. ユーザーとパスワード
+
+``FTP`` は ``host`` 用に (``user`` 、 ``password``) を必要とします。
+``SFTP`` は認証用にパスワードもしくはホストキーを使用できます。
+しかしながら、sshエージェントはベターで、よりセキュアな解決方法です。
+独自のセキュアではない方法を提供しないことにします。
+
+2. ユーザー、領域とパスワード
+
+ホストに対して認証するために ``HTTP`` と ``HTTPS`` は(``user, realm, password``)を必要とします。
+``.htaccess`` ファイルを利用することで、たとえば、任意の ``host``
+に対して (``user, realm, password``) をいくつか定義することが可能です。
+ですので本当に必要なのは (``user``, ``password``, ``host``, ``path``)です。
+``realm`` は定義で考慮されませんが、bzrにパスワードを催促される場合表示されます。
+
+``HTTP proxy`` は適切なポートを指定することで ``HTTP`` (もしくは ``HTTPS``) として扱うことができます。
+
+すべてのスキームを考慮するには、パスワードは認証定義の一式 (``scheme``, ``host``, ``port``, ``path``, ``user``, ``password``) から推定されます。
+
+ * ``scheme``: 空にできます (定義の残りは任意のスキームに対して使用できることを意味する)、
+ ``SFTP`` と ``bzr+ssh`` はここでは使うべきではありません。
+ 代わりに ``ssh`` が使われるべきです。これが認証に関して本当のスキームだからです。
+
+ * ``host``: 空にできます (ホスト用のデフォルトとして振る舞う),
+
+ * ``port`` は空にできます (ホストが同じスキームに対していくつかのサーバーを提供するときに便利)、
+ 数値の値のみが許可され、サーバーがスキームの標準ポートとは異なるポートを使用するときのみにこれは使用されます。
+
+ * ``path``: 空にできます (FTPもしくはSFTPはこれを使用しません),
+
+ * ``user``: 空にできます (デフォルトでは ``bzr`` はpythonの ``getpass.get_user()`` を使用),
+
+ * ``password``: 常にパスワードをプロンプトで入力する方が望ましいのであれば空にできます。
+
+任意のURLに対して、複数の定義を提供できます。
+bzrは次のルールに従って (``user`` [, ``password``]) を選択します:
+
+ 1. 最初にマッチするものが優先される
+
+ 2. すべてにマッチする空のフィールド
+
+ 3. デコレータがリクエストされたURLに使用されていても ``scheme`` はマッチします。
+
+ 4. ``host`` は正確にマッチするか '.' で始まる場合、ドメインとしてふるまいます。
+ (``project.bzr.sf.net`` は ``.bzr.sf.net`` にマッチしますが ``projectbzr.sf.net`` は ``bzr.sf.net`` にマッチしない)。
+
+ 5. ``port`` はリクエストされたURLに含まれる場合(正確にマッチする場合のみ)マッチします。
+
+ 6. ``path`` はリクエストされたURLに含まれる場合マッチします (そして上記のルール #2 によって、
+ 空のパスは任意の提供されたパスにマッチします)。
+
+
+
+ファイルのフォーマット
+----------------------
+
+`設定ファイル`_ 用の一般ルールは変数ポリシー意外に当てはまります。
+
+.. _設定ファイル: #configuration-settings
+
+それぞれのセクションで認証の定義を記述します。
+
+セクションの名前は任意の文字列で、 ``DEFAULT`` の値のみが保存され
+*最後* のセクションとして現れます。
+
+それぞれのセクションは次の内容を定義すべきです:
+
+* ``user``: 使用されるログイン名
+
+それぞれのセクションは次の内容を定義できます:
+
+* ``host``: リモートサーバー
+
+* ``port``: サーバーがリスンしているポート番号
+
+* ``path``: ブランチの位置
+
+* ``password``: パスワード
+
+
+例
+---
+
+
+外部でホストされた個人プロジェクト
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+すべての接続は同じ ``user`` で行われ
+(デフォルトのbzrのものが適切でない場合のためのリモートの接続)
+パスワードはいくつかの例外とともに常に催促されます::
+
+ # hobby.netのPetプロジェクト
+ [hobby]
+ host=r.hobby.net
+ user=jim
+ password=obvious1234
+
+ # ホームサーバー
+ [home]
+ scheme=https
+ host=home.net
+ user=joe
+ password=1essobV10us
+
+ [DEFAULT]
+ # ローカルユーザーがbarbazで、すべてのリモートサイト上ではfoobarとして
+ user=foobar
+
+
+ソースホスティングプロバイダ
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+shp.net(仮想)ドメインにおいて、それぞれのプロジェクトは独自のサイトを持ちます::
+
+ [shpnet domain]
+ # sftpを使用するが、sshは認証用に使用される
+ scheme=ssh
+ # '.' は 'shp.net' だけがマッチしないことを保証する
+ host=.shp.net
+ user=joe
+ # bzrはsftp用のパスワードの提供を保証しません
+ # パスワードをインタラクティブに入力したくなければ
+ # sshエージェントを使用することを考えてください(pageant, ssh-agent、など)
+
+HTTPS、SFTPサーバーとプロキシ
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+company.comにおいて、サーバーのホスティングリリースは統合ブランチの背後にはプロキシがあり、
+2つのブランチは異なる認証ポリシーを使用します::
+
+ [reference code]
+ scheme=https
+ host=dev.company.com
+ path=/dev
+ user=user1
+ password=pass1
+
+ # devサーバー上の開発ブランチ
+ [dev]
+ scheme=ssh # bzr+sshとsftpはここで利用可能
+ host=dev.company.com
+ path=/dev/integration
+ user=user2
+
+ # プロキシ
+ [proxy]
+ scheme=http
+ host=proxy.company.com
+ port=3128
+ user=proxyuser1
+ password=proxypass1
+
+
+計画的な強化
+-------------
+
+次の内容はまだ実装されていませんが進行中の作業の一部として計画されています:
+
+* ``password_encoding`` フィールドの追加は次のとおりです:
+
+ - さまざまな難読化のエンコーディング(たとえばbase64)でパスワードを保存する。
+
+ - パスワードの保存をプラグインに委譲する(たとえば.netrc)。
+
+* ユーザーがユーザー名もしくはパスワードの入力を催促されたらクレデンシャルを更新する。
+
+* ``HTTPS`` 用に ``verify_certificates`` フィールドを追加する。
+
+``password_encoding`` と ``verify_certificates`` フィールドは認識されますが
+実際の実装では無視されます。
+
+
+バグトラッカーの設定
+=====================
+
+コミットを行うとき、その変更によって修正されたバグに関するメタデータは --fixes オプションを使用することで記録されます。
+それぞれのバグが修正されたものとしてマークされるために、エントリーが '<url> <status>' を述べる 'bugs' リビジョンプロパティに含まれます。
+(現在サポートされる ``status`` の値は ``fixed.`` だけです)
+Launchpadの中心バグトラッカー用のサポートは組み込まれています。
+他のバグトラッカーに関して、正しいURLが記録されるように設定が予め要求されます。
+
+Launchpadに加えて、BazaarはBugzillaとTracに適切なURLの生成を直接サポートします。
+プロジェクトが異なるバグトラッカーを使用するのであれば、そのサポートを追加するのは簡単です。
+BugzillaもしくはTracを使用しているのであれば、
+バグトラッカーの基底URLを格納する設定変数を設定することだけが必要です。
+これらのオプションは ``bazaar.conf`` 、 ``branch.conf`` もしくは ``locations.conf`` のブランチ固有のセクションに入ります。
+取り組むプロジェクトごとにこれらの値をセットアップできます。
+
+注: それぞれのトラッカーに対して短縮名を提供するのであれば、望むのであればコミット時に1つもしくは複数のトラッカーで1つもしくは複数のバグを指定できます。
+
+Launchpad
+---------
+
+バグ2を修正するコミットを記録するには ``bzr commit --fixes lp:2`` を使用します。
+
+bugzilla_<tracker_abbreviation>_url
+-----------------------------------
+
+存在するのであれば、Bugzillaのバグトラッカーの位置は <tracker_abbreviation> によって参照されます。
+そのバグトラッカーのバグをそのコミットで修正されたものとしてマークするためにはこのオプションは ``bzr commit --fixes`` と一緒に使用できます::
+
+ bugzilla_squid_url = http://www.squid-cache.org/bugs
+
+上記の例はSquidのバグ 1234が修正されたものとしてマークするために ``bzr commit --fixes squid:1234`` を許可します。
+
+trac_<tracker_abbrevation>_url
+------------------------------
+
+存在するのであれば、Tracインスタンスの位置は <tracker_abbreviation> によって参照されます。
+そのコミットによってバグが修正されたものとしてそのトラッカーの中でマークするためにこのオプションは ``bzr commit --fixes`` と一緒に使用できます::
+
+ trac_twisted_url = http://www.twistedmatrix.com/trac
+
+上記の例はTwistedのバグ1234を修正したものとしてマークするために ``bzr commit --fixes twisted:1234`` を許可します。
+
+bugtracker_<tracker_abbrevation>_url
+------------------------------------
+
+存在するのであれば、一般的なバグトラッカーのインスタンスの位置は <tracker_abbreviation> によって参照されます。
+位置は ``{id}`` プレースホルダーを含まなければなりません。プレースホルダーは特定のバグIDに置き換えられます。
+そのコミットによってバグが修正されたものとしてそのトラッカーでマークするためにこのオプションを ``bzr commit --fixes`` と一緒に使用できます::
+
+ bugtracker_python_url = http://bugs.python.org/issue{id}
+
+上記の例はPythonのRoundupバグトラッカーのバグ1234を修正されたものとしてマークするために ``bzr commit --fixes python:1234`` を許可します::
+
+ bugtracker_cpan_url = http://rt.cpan.org/Public/Bug/Display.html?id={id}
+
+上記はCPANのRTバグトラッカー用です。
+
+
+.. _configuration-settings:
+
+構成設定
+=========
+
+.. TODO: Should have some explanation of why you'd want things in
+.. branch.conf.
+
+
+環境変数の設定
+---------------
+
+大抵の設定が設定ファイルによって取り扱われる一方で、
+半永久的ないくつかのオプションは環境変数を通して制御できます。
+
+BZR_EMAIL
+~~~~~~~~~
+
+Bazaarによって使用されるEメールのIDを上書きする。よくあるフォーマット::
+
+ "John Doe <jdoe@example.com>"
+
+``email`` の設定値も参照してください。
+
+BZR_PROGRESS_BAR
+~~~~~~~~~~~~~~~~
+
+進行状況の表示方法を上書きする。可能な値は "none"、 "dots"、 "tty"
+
+BZR_SIGQUIT_PDB
+~~~~~~~~~~~~~~~
+
+SIGQUITが通常とおりに振る舞うようにするかもしくはブレークインデバッガーを起動するかどうか制御する。
+
+* 0 = 標準のSIGQUITのふるまい(通常はコアダンプを伴ってexitする)
+* 1 = ブレークインデバッガーを起動する (デフォルト)
+
+BZR_HOME
+~~~~~~~~
+
+Bazaarによって使用されるホームディレクトリを上書きする
+
+BZR_SSH
+~~~~~~~
+
+異なるSSHの実装を選択する。
+
+BZR_PDB
+~~~~~~~
+
+デバッガもしくはエラーを立ち上げるか制御する。
+
+* 0 = Standard behavior
+* 1 = Launch debugger
+
+BZR_REMOTE_PATH
+~~~~~~~~~~~~~~~
+
+bzr+sshプロトコルを使用する際に使用するBazaar実行ファイルへのパス。
+
+設定値 ``bzr_remote_path`` も参照。
+
+BZR_EDITOR
+~~~~~~~~~~
+
+コミットメッセージなどの際にBazaarが使用するエディタへのパス。
+
+BZR_PLUGIN_PATH
+~~~~~~~~~~~~~~~
+
+Bazaarが使用するプラグインディレクトリへのパス。
+
+BZRPATH
+~~~~~~~
+
+Bazaarがシェルシェルプラグインの外部コマンドを探すパス。
+
+
+設定ファイル
+-------------
+
+設置場所
+~~~~~~~~~
+
+設定ファイルはLinux/Unixの場合 ``$HOME/.bazaar`` に
+Windowsの場合 ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` に設置されます。
+( ``bzr version`` を使用することでシステムに設置された位置をチェックできます)
+
+この位置に3つの主要な設定ファイルが存在します:
+
+* ``bazaar.conf`` はデフォルトの設定オプションを記述します
+
+* ``locations.conf`` は特定のブランチの位置用の設定情報を記述します。
+
+* ``authentication.conf`` はリモートサーバー用のクレデンシャル情報を記述します。
+
+それぞれのブランチはそのブランチに固有な値を設定する設定ファイルも格納します。
+このファイルはブランチの範囲内の ``.bzr/branch/branch.conf`` で見つかります。
+このファイルはブランチのすべてのユーザーに見えます。
+あなたのブランチ専用に設定値の1つを上書きしたいのであれば、 ``locations.conf`` で行うことができます。
+
+一般的なフォーマット
+~~~~~~~~~~~~~~~~~~~~
+
+iniファイルは3つの種類のコントラクト: セクションヘッダー、セクション変数とコメントを持ちます。
+
+コメント
+^^^^^^^^^
+
+コメント行は "#" で始まります("hash mark", "pound sign" "number sign"とも呼ばれます)。
+コメント行はiniファイルを解析するときBazaarによって無視されます。
+
+セクションヘッダー
+^^^^^^^^^^^^^^^~~~~
+
+セクションヘッダーは行頭から始まり角かっこで囲まれた単語です。
+典型的なセクションヘッダーは次のとおりです::
+
+ [DEFAULT]
+
+bazaar.confに対して現時点で唯一有効なセクションヘッダーは[DEFAULT]と[ALIASES]です。
+セクションヘッダーは大文字と小文字を区別します。
+デフォルトのセクションが提供する設定変数はブランチの設定ファイルで上書きできます。
+
+``locations.conf`` に対して、
+セクションにマッチする最長のものを持つセクションからの変数は潜在的に有効な別のセクションヘッダーを除外するために使われます。
+セクションヘッダーはブランチ用のパスをセクションヘッダーとして使用します。次のような例があります::
+
+ [http://mybranches.isp.com/~jdoe/branchdir]
+ [/home/jdoe/branches/]
+
+
+セクション変数
+^^^^^^^^^^^^^^^
+
+セクション変数はセクションの範囲に属します。セクション変数は変数名、等号と値を格納します。例です::
+
+ email = John Doe <jdoe@isp.com>
+ check_signatures = require
+
+
+変数のポリシー
+^^^^^^^^^^^^^^^
+
+セクションの中で定義された変数は名前つきのディレクトリもしくはURLに加えてそれらを格納する位置にも影響を与えます。
+ポリシーは可変変数が含まれる位置のために解釈される方法を変更するために使用できます。現在は3つのポリシーが利用できます:
+
+ none:
+ 値は含まれる位置に対して同じように解釈されます。
+ これはデフォルトのふるまいです。
+ norecurse:
+ 値はセクション名によって指定された正確な位置のみに対して使用されます。
+ appendpath:
+ for contained locations, 追加パスのコンポーネントは値に追加されます。
+
+ポリシーは "$var:policy" 形式の名前を持つキーによって指定されます。
+たとえば、ブランチのツリー用のpushの位置を定義するには、次の設定が使われます::
+
+ [/top/location]
+ push_location = sftp://example.com/location
+ push_location:policy = appendpath
+
+この設定によって、 ``/top/location/branch1`` 用のpush位置は ``sftp://example.com/location/branch1`` になります。
+
+
+主要な設定ファイルのbazaar.conf
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``bazaar.conf`` は ``[DEFAULT]`` と呼ばれる1つのセクションだけを許可します。
+このデフォルトセクションはすべてのブランチ用のデフォルト設定オプションを格納します。
+デフォルトセクションは ``locations.conf`` にブランチ固有のセクションを提供することで上書きできます。
+
+典型的な ``bazaar.conf`` セクションは次のようになります::
+
+ [DEFAULT]
+ email = John Doe <jdoe@isp.com>
+ editor = /usr/bin/vim
+ check_signatures = check-available
+ create_signatures = when-required
+
+
+ブランチの位置の設定ファイルのlocations.conf
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``locations.conf`` によって特定のブランチ用に設定を上書きできます。
+フォーマットは1つの重大な変更を伴うbazaar.confのデフォルトセクションに対してほとんど理想的です:
+デフォルトを記述する代わりに、セクションヘッダーは値を上書きしたいブランチへのパスになります。
+ワイルドカードの '?' と '*' がサポートされます::
+
+ [/home/jdoe/branches/nethack]
+ email = Nethack Admin <nethack@nethack.com>
+
+ [http://hypothetical.site.com/branches/devel-branch]
+ create_signatures = always
+ check_signatures = always
+
+ [http://bazaar-vcs.org/bzr/*]
+ check_signatures = require
+
+認証用の設定ファイル、authentication.conf
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+``authentication.conf`` によってリモートサーバー用のクレデンシャルを指定できます。
+これはすべてのサポートされる転送と認証(たとえばsmtp)を必要とするbzrの一部に対して使用できます。
+
+ファイルの構文は適用しない変数ポリシー用の他の例外を除いて同じルールに従います。
+
+設定ファイルにおける認証の使い方の詳細な情報に関しては `認証の設定`_ を参照してください。
+
+
+変数の共通オプション
+---------------------
+
+email
+~~~~~
+
+Eメールアドレスはブランチをコミットする際に使われます。よく次のような形式をとります::
+
+ email = Full Name <account@hostname.tld>
+
+editor
+~~~~~~
+
+コミットメッセージなしで *bzr commit* が実行された場合に使用されるエディタのパスです。
+この設定は環境変数 ``BZR_EDITOR`` によって設定され、
+環境変数 ``VISUAL`` と ``EDITOR`` によって上書きされます。
+
+check_signatures
+~~~~~~~~~~~~~~~~
+
+署名用のふるまいを定義します。
+
+require
+ リビジョン用のgnupg署名が存在して有効でなければなりません。
+
+ignore
+ リビジョンのgnupgの署名をチェックしない。
+
+check-available
+ (デフォルト) リビジョン用のgnupgの署名が存在する場合、それらをチェックします。
+ わるい署名であることが分かるとBazaarは失敗しますが、署名が存在しない場合は失敗しません。
+
+create_signatures
+~~~~~~~~~~~~~~~~~
+
+リビジョン署名のふるまいを定義します。
+
+always
+ コミットされるすべての新しいリビジョンに署名する。
+
+when-required
+ (デフォルト) ブランチが署名つきのリビジョンを要求するときのみ新しくコミットされたリビジョンに署名する。
+
+never
+ ブランチが署名を要求する場合でも新しくコミットされたリビジョンに署名するのを拒否する。
+
+recurse
+~~~~~~~
+
+``locations.conf`` でのみ便利です。
+このセクション用の設定をサブディレクトリにも適用するかどうか定義します:
+
+true
+ (デフォルト このセクションはサブディレクトリにも適用される。
+
+false
+ このセクションはこのディレクトリのブランチのみに適用されその下のブランチには適用されない。
+
+gpg_signing_command
+~~~~~~~~~~~~~~~~~~~
+
+(デフォルト: "gpg"). リビジョンの署名とチェックのために使用されるプログラム。例です::
+
+ gpg_signing_command = /usr/bin/gnpg
+
+bzr_remote_path
+~~~~~~~~~~~~~~~
+
+(デフォルト: "bzr"). bzr用のスマートサーバーを稼働させるために使われるコマンドへのパス。
+この値はlocations.confでのみ指定が許可されます。理由は次のとおりです:
+
+- branch.confがアクセスできる前に必要だから
+- セキュリティリスクになるコマンドを指定するためにリモートのbranch.confファイルを許可するから
+
+これはBZR_REMOTE_PATH 環境変数によって上書きされます。
+
+smtp_server
+~~~~~~~~~~~
+
+(デフォルト: "localhost")。たとえば ``merge-directive --mail-to`` 、もしくはbzr-emailプラグインによって
+BazaarがEメールを送信する必要があるときに使用するSMTPサーバー、
+
+
+smtp_username, smtp_password
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+SMTPサーバーで認証するユーザーとパスワード。
+smtp_usernameが設定されていて、smtp_passwordが設定されていなければ、Bazaarはパスワードを催促します。
+Eメールを送信するためにSMTPサーバーが認証を必要とする場合のみこれらの設定が必要です。
+
+mail_client
+~~~~~~~~~~~
+
+マージリクエストを送信するために使うメールクライアント。
+デフォルトでは、Windowsではbzrは ``mapi`` を使うことを試みます。
+他のプラットフォームでは、 ``xdg-email`` を試みます。
+これらのどちらかが失敗すると、 ``editor`` に戻ります。
+
+特定のクライアント用のサポートされた値:
+
+:claws: Clawsを使用する。ファイル添付のダイアログはスキップする。
+:evolution: Evolutionを使用する
+:kmail: KMailを使用する
+:mutt: Muttを使用する
+:thunderbird: Mozilla ThunderbirdもしくはIcedoveを使用する。Thunderbird/Icedove 1.5に関して、
+ これはxdg-emailが扱えないいくつかのバグに対処します。
+
+サポートされる一般的な値は次のとおりです:
+
+:default: 上記を参照。
+:editor: マージリクエストを書くエディタを使用します。
+ これはコミットID( ``bzr whoami`` を参照),
+ smtp_serverと(オプションで)smtp_usernameとsmtp_passwordも使用します。
+:mapi: Windowsで好きなメールクライアントを使用します。
+:xdg-email: 好きなメールプラグラムを実行するためにxdg-emailを使用する
+
+submit_branch
+~~~~~~~~~~~~~
+
+現在の作業内容を投稿しようとしているブランチ。
+これは ``bzr send`` によって自動的に設定され ``submit:`` リビジョンスペックにも使用されます。
+通常、これはブランチ単位ロケーション単位で設定されます。
+
+public_branch
+~~~~~~~~~~~~~
+
+このブランチの公開されアクセス可能なバージョン
+(このブランチが公開されてアクセス可能ではないことを暗示する)。
+``bzr send`` によって使用されます(そして設定されます)。
+
+
+ブランチ特有のオプション
+-------------------------
+
+これらのオプションは ``dirstate-tags`` もしくは後のフォーマットを使用するブランチにのみ適用します。
+通常これらは自動的に ``.bzr/branch/branch.conf`` 設定される
+もしくは手動で ``locations.conf`` もしくは ``bazaar.conf`` に設定されます。
+
+append_revisions_only
+~~~~~~~~~~~~~~~~~~~~~
+
+"True"に設定されていればリビジョンはログにのみ追加され、削除されません。
+この設定が有効なブランチは、他のブランチのログがそれ自身のリビジョンより長い場合、別のブランチからのみpullできます。
+通常これは ``bzr init --append-revisions-only`` によって設定されます。
+
+parent_location
+~~~~~~~~~~~~~~~
+
+存在すれば、pullもしくはmerge用のデフォルトブランチの位置。
+通常このオプションは ``pull --remember`` もしくは ``merge --remember`` によって設定されます。
+
+push_location
+~~~~~~~~~~~~~
+
+存在すれば、push用のデフォルトブランチの位置。
+通常このオプションは ``push --remember`` によって設定されます。
+
+bound_location
+~~~~~~~~~~~~~~
+
+チェックアウトとして振る舞うときコミットが向かう位置。
+通常このオプションは ``bind`` によって設定されます。
+
+bound
+~~~~~
+
+"True"に設定されていると、ブランチはチェックアウトとしてふるまい、bound_locationにそれぞれのコミットをpushします。
+通常このオプションは ``bind``/``unbind`` に設定されます。
+
+
+衝突のタイプ
+=============
+
+オペレーションの中には、merge、revertとpullのように、作業ツリーの内容を修正するものがあります。
+これらの修正はプログラムで生成されるので、作業ツリーの現在の状態と衝突することがあります。
+多くの種類の変更はプログラムで結合できますが、 正しいことを行われているか時々人間だけしか判断できないことがあります。
+これが起きるとき Bazaarはあなたに衝突が存在するのでそれを解消するように伝えます。
+Bazaarに衝突が解消したことを伝えるコマンドは ``resolve`` ですが、
+これを実行できる前にいくつかのアクションを実行しなければなりません。
+
+それぞれの衝突は下記のセクションで説明され、衝突を解消するために行わなければならないアクションの概要が説明されています。
+
+
+テキストの衝突
+---------------
+
+典型的なメッセージは次のとおりです::
+
+ Text conflict in FILE
+
+テキストのマージが2つのセットのテキストの変更を完全に折り合いをつけられないときにこれらは生み出されます。
+BazaarはTHIS、OTHER、とBASEのエクステンションでそれぞれのバージョン用にファイルをemitします。
+THISはターゲットツリーからのファイルのバージョン、すなわち、変更をマージしようとしているツリーです。
+OTHERはターゲットにマージしようとしているバージョン、BASEは比較用のベースとして使われる古いバージョンです。
+
+ファイルのメインコピーにおいて、Bazaarは調整できるすべての変更を含み、
+未調整の衝突は ``<<<<<<<`` のように "herringbone" マーカーによって囲まれます。
+
+たとえば、初期のテキストが "The project leader released it."、でTHISはこれを "Martin Pool released it." に修正する一方で、
+OTHERは"The project leader released Bazaar."に修正します。衝突は次のようになります::
+
+ <<<<<<< TREE
+ Martin Pool released it.
+ =======
+ The project leader released Bazaar.
+ >>>>>>> MERGE-SOURCE
+
+正しい解消方法は"Martin Pool released Bazaar."になります。
+
+ファイルのメインコピーを編集する、もしくはTHIS、OTHERとBASEバージョン上で外部ツールを起動することのどちらかでテキストの衝突を扱うことができます。
+テキストの衝突の解消において他のものから変更のセットの1つの選別はめったにないことは言っておく価値があります。
+
+より頻繁に、2つのセットの変更はインテリジェントに結合しなければなりません。
+
+メインコピーを編集するとき、 herringbone マーカーを必ず削除してください。
+編集作業を終えたとき、ファイルは衝突がけっして起こらないようであれば、コミットする準備ができています。
+
+テキストの衝突を解消したとき、"bzr resolve"を実行するだけでBazaarは解消した衝突を自動検出します。
+
+内容の衝突
+----------
+
+典型的なメッセージ::
+
+ Contents conflict in FILE
+
+ターゲットツリーとマージソースの中の変更の衝突が存在するときにこの衝突は起こりますが、
+が衝突したアイテムはテキストファイルではありません。
+これらはバイナリファイルもしくはシンボリックリンクもしくはディレクトリになります。
+片方が削除され、もう一方が修正されたファイルでも起こり得ます。
+
+テキストの衝突のように、BazaarはTHIS、OTHER とBASEファイルをエミットしますが
+(これらは通常のファイル、シンボリックリンクもしくはディレクトリになります)、
+これはherringbone衝突マーカーを持つファイルの"メインコピー"を含みません。
+"メインコピー"がTHISもくはOTHERにリネームされたときにこれは現れます。
+
+これを解消するには、ファイルを通常の名前に戻すために "bzr mv" を使用し変更を手動で結合します。
+満足したときに、 "bzr resolve FILE" を実行します。この種の衝突が解消されたときにBazaarは自動検出できません。
+
+重複したパス
+-------------
+
+典型的なメッセージ::
+
+ Conflict adding file FILE. Moved existing file to FILE.moved.
+
+時々Bazaarはすでに使用されているパス名を用いてファイルを作成しようとします。
+既存のファイルは "FILE.moved" にリネームされます。
+望むのであれば、これらのファイルの1つをリネームするか、それらの内容を結合できます。
+満足したら、衝突を解消したものとしてマークするために "bzr resolve FILE" を実行できます。
+
+バージョン管理下にない親
+-------------------------
+
+典型的なメッセージ::
+
+ Conflict because FILE is not versioned, but has versioned children.
+
+ときどきBazaarは親ディレクトリがバージョン管理されていないファイルを作成しようとします。
+ターゲットの中でディレクトリが削除されたときにこれが起こりますが、
+ソースの中の新しい子を持ちます。逆も同様です。
+この状況において、Bazaarは親ディレクトリも同様にバージョン管理します。
+この問題の解決方法は特定のシナリオに大きく依存します。
+ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。
+満足したら、衝突を解消したものとして"bzr resolve FILE"を実行できます。
+
+見つからない親
+---------------
+
+典型的なメッセージ::
+
+ Conflict adding files to FILE. Created directory.
+
+ターゲットの中でファイルを削除するときにこれが起こりますが、ソースの中に新しい子があります。
+これは "unversioned parent" の衝突と似ています。
+バージョン管理を解除される代わりに、親ディレクトリが *存在しない* ことを除いて、
+この状況において、Bazaarは見つからない親を作成します。
+この問題の解決方法は特定のシナリオに大いに依存します。
+ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。
+満足したら、衝突を解消したものとして "bzr resolve FILE" を実行できます。
+
+親を削除する
+------------
+
+典型的なメッセージ::
+
+ Conflict: can't delete FILE because it is not empty. Not deleting.
+
+これは"見つからない親"の反対です。ソースの中でディレクトリは削除されますが、
+ターゲットの中で新しい子はあります。Bazaarはディレクトリを保有し続けます。
+この問題の解消は特定のシナリオに大いに依存します。
+ファイルもしくはディレクトリをリネームもしくは削除するとよいでしょう。
+満足したら、衝突を解消したものとしてマークするために"bzr resolve FILE"を実行できます。
+
+パスの衝突
+-----------
+
+典型的なメッセージ::
+
+ Path conflict: PATH1 / PATH2
+
+ソースとターゲットがファイルの名前もしくは親ディレクトリを修正したときに起こります。
+Bazaarはソースからパス要素を使用します。
+ファイルをリネームできれば、衝突を解消したものとしてマークするために "bzr resolve FILE" を実行します。
+
+親のループ
+-----------
+
+典型的なメッセージ::
+
+ Conflict moving FILE into DIRECTORY. Cancelled move.
+
+ソースとターゲットがそれぞれディレクトリを移動させたので、
+変更が適用可能であれば、ディレクトリはそれ自身を含むときにこれは起こります。
+例です::
+
+ $ bzr init
+ $ bzr mkdir a
+ $ bzr mkdir b
+ $ bzr commit -m "BASE"
+ $ bzr branch . ../other
+ $ bzr mv a b
+ $ bzr commit -m "THIS"
+ $ bzr mv ../other/b ../other/a
+ $ bzr commit ../other -m "OTHER"
+ $ bzr merge ../other
+
+この状況において、Bazaarは移動をキャンセルして、"a"を"b"の中に残しておきます。
+望むのであればディレクトリをリネームできれば
+衝突を解消したものとしてマークするために "bzr resolve FILE" を実行します。
+
+ディレクトリではない親
+-----------------------
+
+典型的なメッセージ::
+
+ Conflict: FILE.new is not a directory, but has files in it.
+ Created directory.
+
+片方がファイルをディレクトリを追加したとき、もう一方がディレクトリをファイルもしくはシンボリックリンクに変更したときにこれは起きます。
+例です::
+
+ $ bzr init
+ $ bzr mkdir a
+ $ bzr commit -m "BASE"
+ $ bzr branch . ../other
+ $ rmdir a
+ $ touch a
+ $ bzr commit -m "THIS"
+ $ bzr mkdir ../other/a/b
+ $ bzr commit ../other -m "OTHER"
+ $ bzr merge ../other
+
+
+MalformedTransform
+-------------------
+
+Bazaarに例外のMalformedTransformを起動させること可能です(非常にまれですが)。
+これはBazaarが解決できないファイルシステムの衝突に遭遇したことを意味します。
+通常これはバグを示します。これに遭遇したら教えて頂くようお願いします。
+バグトラッカーは https://launchpad.net/bzr/+bugs です。
+
+
+現在のストレージフォーマット
+============================
+
+:pack-0.92:
+ (ネイティブ) (デフォルト) 0.92で新しく導入:
+ dirstate-tagsフォーマットリポジトリと互換性のあるデータを持つパックベースのフォーマット。
+ 0.92以前のbzrリポジトリと相互運用できますが0.92以前のbzrでは読めません。
+ 以前はknitpack-experimentalと呼ばれていました。詳細な情報に関しては、
+ http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
+
+:1.6:
+ (ネイティブ) スタックをサポートするディレクトリに基づいたブランチとパック。
+
+:1.6.1-rich-root:
+ (ネイティブ) スタックとリッチrootデータをサポートするブランチとパックベースのリポジトリ(bzr-svnが必要)
+
+:1.9:
+ (ネイティブ) btreeインデックスを使用するブランチとパックベースのリポジトリ。
+
+:1.9-rich-root:
+ (ネイティブ) btreeインデックスとrich rootデータを使用する
+ ブランチとパックベースのリポジトリ(bzr-svnに必要)。
+
+
+ストレージフォーマットは ``bzr help formats`` を参照。
+
+
+環境変数
+========
+
+================ =================================================================
+BZRPATH bzrがシェルプラグインコマンドを探すパス。
+BZR_EMAIL ユーザーのEメールアドレス。EMAILを上書きする。
+EMAIL ユーザーのEメールアドレス。
+BZR_EDITOR コミットメッセージの編集用エディタ。EDITORを上書きする。
+EDITOR コミットメッセージの編集用エディタ
+BZR_PLUGIN_PATH bzrがプラグインを探すパス。
+BZR_HOME .bazaarの設定ディレクトリを保持するディレクトリ。HOMEを上書きする。
+BZR_HOME (Win32) bazaar設定ディレクトリを保持するディレクトリ。APPDATAとHOMEを上書きする。
+BZR_REMOTE_PATH リモート'bzr'コマンドのフルネーム(bzr+ssh:// URL用).
+BZR_SSH SSHクライアント: paramiko (デフォルト), openssh, ssh, plink.
+BZR_LOG .bzr.logの位置(ロギングを停止するには'/dev/null'を使う)。
+BZR_LOG (Win32) .bzr.logの位置(ロギングを停止するには'NUL'を使う)。
+================ =================================================================
+
+
+ファイル
+========
+
+:On Linux: ~/.bazaar/bazaar.conf
+:On Windows: C:\\Documents and Settings\\username\\Application Data\\bazaar\\2.0\\bazaar.conf
+
+ユーザーのデフォルト設定は上記のとおりです。
+``[DEFAULT]`` セクションすべての場所に適用される一般的な設定を定義するために使用できます。
+``[ALIASES]`` セクションは共通に使用されるオプション用のコマンドエイリアスを作成するために使用できます。
+
+典型的な設定ファイルは次のとおりです::
+
+ [DEFAULT]
+ email=John Doe <jdoe@isp.com>
+
+ [ALIASES]
+ commit = commit --strict
+ log10 = log --short -r -10..-1
+
+
+グローバルオプション
+=====================
+
+これらのオプションは任意のコマンドで使用可能で、コマンドの前で入力します(たとえば"bzr --profile help")。
+
+--version バージョン番号を表示する。コマンドの前に入力しなければならない。
+--no-aliases このコマンドを実行する際にコマンドエイリアスを処理しない。
+--builtin プラグインのコマンドではなく、組み込みのコマンドを使用する。
+ このオプションは他のプラグインの効果を抑制しない。
+--no-plugins プラグインを処理しない。
+
+--profile ホットスポットプロファイラを使用するプロファイルの実行。
+--lsprof lsprofプロファイラを使用したプロファイルの実行。
+--lsprof-file lsprofプロファイラを使用するプロファイルを実行し、結果を指定ファイルに書き込む。
+ ファイル名が".txt"で終わる場合, テキストフォーマットが使用されます。
+ ファイル名が"callgrind.out"で始まる、もしくは".callgrind"で終わる場合、
+ KCacheGrind用に出力がフォーマットされる。
+ さもなければ、出力はpickleになる。
+--coverage 指定ディレクトリの行カバレージレポートを生成する。
+
+プロファイリングに関する詳細な情報はdoc/developers/profiling.txtを参照してください。
+トラブルシューティングと開発を手助けするためのたくさんのデバッグフラッグも利用可能です。
+
+-Dauth 使用される認証セクションをトレースする。
+-Derror 通常のエラーハンドリングの代わりに、常にエラー上のトラックバックを表示する。
+-Devil 割高なもしくはわるいスケーリングオペレーションを行うコールサイトをキャプチャする。
+-Dfetch リポジトリ間のコピーの履歴をトレースする。
+-Dhashcache ハッシュを決定するために作業ファイルが読み込まれるたびにログを記録する
+-Dhooks フックの実行をトレースする。
+-Dhpss スマートプロトコルリクエストとレスポンスをトレースする。
+-Dhttp http接続、リクエストとレスポンスをトレースする。
+-Dindex 主要なindexオペレーションをトレースする。
+-Dknit knitオペレーションをトレースする。
+-Dlock lockdirロックがとられるもしくはリリースされるときをトレースする。
+-Dmerge マージのデバッグ用の情報を表示する。
+-Dpack packオペレーション用の情報を表示する。
+
+
+フック
+=======
+
+紹介
+-----
+
+*yyy* クラスの *xxx* タイプのフックを使用するには登録する必要があります::
+
+ yyy.hooks.install_named_hook("xxx", ...)
+
+例に関してはユーザーガイドの `フックを利用する`_ を参照してください。
+
+.. _フックを利用する: ../user-guide/index.html#id186
+
+それぞれのフックが含むクラスは下記のそれぞれのフックタイプの後で丸かっこの中で示されます。
+
+それぞれの説明ではクライアント(bzrが実行されるマシン)もしくはサーバー
+(ブランチURLで示されるマシン)で実行されるか示します。
+これらは必ずしも同じマシンではありません。
+
+以下の1つがtrueの場合(フックを含む)プラグインはサーバー上で実行されます:
+
+ * リモートブランチがクライアントと同じマシン上にあり、クライアントはプラグインを有効にしている。
+
+ * 接続はスマートサーバー経由で行われ("bzr://"、"bzr+ssh://"もしくは"bzr+http://"で
+ 始まるURLでアクセスするもしくはスマートサーバーがHTTP経由で利用可能なときに
+ "http://"でアクセスする)、サーバーがプラグインを有効にしている。
+
+
+open (Branch)
+-------------
+
+Branchオブジェクトが開いた後で、Branchオブジェクトによって呼び出されます。
+クライアントとサーバーで実行します。
+
+post_push (Branch)
+------------------
+
+``push`` が完了した後で実行されます。
+クライアントで実行します。
+
+フックのシグネチャは (push_result) でメンバーを含みます。
+
+ source_branch
+ データがpushされる場所(読み込みはロックされる)。
+ これは最も低いレイテンシブランチになります。
+
+ target_branch
+ データが送信される直接の場所(書き込みがロックされる)。
+
+ master_branch
+ target_branch、もしくはターゲットがバインドされたブランチの場合、
+ これはマスターロケーションになります(書き込みはロックされる)。
+
+ local_branch
+ ターゲットがバインドされたブランチの場合、これがターゲットブランチになる、
+ そうでなければ、Noneになります。
+
+ old_revno
+ push以前のブランチのリビジョン番号(たとえば10)。
+
+ old_revid
+ push以前のリビジョンid (たとえば joe@foo.com-1234234-aoeua34)。
+
+ new_revno
+ push後のブランチのリビジョン番号(たとえば12)。
+
+ new_revid
+ push後のリビジョンid (たとえば joe@foo.com-5676566-boa234a)
+
+
+post_pull (Branch)
+------------------
+
+``pull`` が完了し後で実行されます。
+
+フックのシグネチャは (push_result) で次のメンバーを含みます:
+(source, local, master, old_revno, old_revid, new_revno, new_revid)。
+localはローカルのターゲットブランチもしくはNoneで、
+masterはターゲットのマスターブランチで、残りは見たとおりです。
+sourceでは読み込みがロックされターゲットブランチでは書き込みがロックされます。
+sourceはローカルの低レイテンシブランチになります。
+
+
+start_commit (MutableTree)
+--------------------------
+
+``commit`` が作業ツリーの処理を始める前に作業ツリー上で実行されます。
+クライアントで実行します。
+
+``pre_commit`` フック(下記を参照)とは異なり、
+``start_commit`` フックは作業ツリーを安全に変更できます。
+
+フックのシグネチャはツリーがMutableTreeオブジェクトである場所(ツリー)です
+
+
+pre_commit (Branch)
+-------------------
+
+``commit`` が完了する前に実行されます。
+クライアントで実行します。
+
+フックのシグネチャは
+(local, master, old_revno, old_revid, future_revno, future_revid, tree_delta, future_tree)です。
+old_revnoはブランチに最初にコミットするためのNULL_REVISIONで、
+tree_deltaは基底リビジョンからの変更を記述するTreeDeltaオブジェクトで、
+future_treeはインメモリツリーでCommitBuilder.revision_tree()から得られます。
+フックはtree_deltaとfuture_treeを修正する *必要はありません* 。
+
+
+post_commit (Branch)
+--------------------
+
+``commit`` が完了した後で実行されます。
+クライアントで実行します。
+
+フックのシグネチャは (local, master, old_revno, old_revid, new_revno, new_revid)です。
+old_revidはブランチへの最初のコミットのためのNULL_REVISIONです。
+
+
+post_uncommit (Branch)
+----------------------
+
+``uncommit`` が完了した後で実行されます。
+
+apiのシグネチャは (local, master, old_revno, old_revid, new_revno, new_revid)です。
+localはローカルブランチもしくはNoneで、masterはターゲットブランチで、
+空のブランチは0のnew_revno、Noneのnew_revidを受け取ります。
+
+
+pre_change_branch_tip (Branch)
+-------------------------------
+
+ブランチの書き込みがロックされている間に、ブランチチップが変更される前に実行されます。
+クライアントとサーバーで実行します。
+push、pull、commitとuncommitのすべてはこのフックを起動させることに注意してください。
+
+フックのシグネチャは (params) で、paramsはメンバーを含むオブジェクトです。
+
+ branch
+ チップが変更されるブランチ。
+
+ old_revno
+ 変更前のブランチのリビジョン番号(たとえば10)。
+
+ old_revid
+ 変更前のリビジョンid (たとえば joe@foo.com-1234234-aoeua34)。
+
+ new_revno
+ 変更後のブランチのリビジョン番号(たとえば12)。
+
+ new_revid
+ 変更後のリビジョンid (たとえば joe@foo.com-5676566-boa234a)。
+
+ヘッドリビジョンはドットつきのリビジョン番号をけっして持たないので、old_revnoとnew_revnoメンバーは整数です。
+
+
+post_change_branch_tip (Branch)
+-------------------------------
+
+ブランチの書き込みがまだロックされている間にブランチのチップが変更された後に実行されます。
+クライアントとサーバーで実行します。
+push、pull、commitとuncommitすべてがこのフックを起動させることに注意してください。
+
+フックシグネチャは(params)で、paramsは次のメンバーを含むオブジェクトです。
+
+ branch
+ チップが変更されるブランチ。
+
+ old_revno
+ 変更前のブランチのリビジョン番号 (たとえば10)。
+
+ old_revid
+ 変更前のリビジョンid(たとえば joe@foo.com-1234234-aoeua34)。
+
+ new_revno
+ 変更後のブランチのリビジョン番号(たとえば12)。
+
+ new_revid
+ 変更後のリビジョンid(たとえば joe@foo.com-5676566-boa234a)。
+
+ヘッドリビジョンはドットつきのリビジョン番号をけっして持たないのでold_revnoとnew_revnoメンバーは整数です。
+
+
+set_rh (Branch)
+---------------
+
+注意: このフックは廃止され近い将来の内に削除されます。
+代わりに ``post_change_branch_tip`` フックを使用してくださるようお願いします。
+
+
+transform_fallback_location (Branch)
+------------------------------------
+
+スタックドブランチとして起動させ、フォールバックロケーションをアクティベイトします。
+
+フックのシグネチャは(branch, url)です:
+
+ branch
+ 開いたブランチ。まだフォールバックロケーションがアクティベイトされなければ、
+ ブランチは半分ビルドされたものとして扱われることに注意してください。
+
+ url
+ フォールバックロケーション用にブランチが指定されたURL。
+ フックはフォールバックロケーションを含むブランチのためにURLを返さなければなりません。
+ 複数のフックが登録されていると、呼び出される順番は未定義で変更の影響を受けます。
+
+(1.9の新しい機能)
+
+
+server_started (SmartTCPServer)
+-------------------------------
+
+サーバーがディレクトリのサービスを提供始めるたびに起動します。
+サーバーで実行されます。
+フックのシグネチャは (backing urls, public url)です。
+
+ backing_url
+ サーバー固有のディレクトリの位置を渡す(string) URLのリスト。
+
+ public_url
+ ディレクトリ用の公開URL。
+
+
+server_stopped (SmartTCPServer)
+-------------------------------
+
+サーバーがディレクトリの提供を停止するときに常に起動します。
+サーバーで実行します。
+フックのシグネチャは ``server_started`` と同じです。
+
+
+lock_acquired (LockDir)
+----------------------------
+
+ロックの取得が成功したときにLockResultオブジェクトで呼び出されます(1.8で導入)。
+
+lock_released (LockDir)
+----------------------------
+
+ロックのリリースが成功したときにLockResultオブジェクトで呼び出されます(1.8で導入)。
+クライアントで実行します。
+
+
+commit_message_template (msgeditor)
+-----------------------------------
+
+コミットメッセージテンプレートを生成するためにコミットによって起動する。
+それぞれのフックはコミットメッセージテンプレートを修正できます。
+フックのシグネチャは (commit, start_message)です:
+
+ commit
+ 進行中のコミットのための、コミットオブジェクト
+
+ start_message
+ オリジナルのコミットメッセージで、初期はNone。
+
+フックは新しいコミットメッセージテンプレートを返します。
+
+(1.10の新しい機能)
+
+
+その他のストレージフォーマット
+==============================
+
+実験的なフォーマットは次のとおりです。
+
+:1.12-preview:
+ (ネイティブ) ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
+
+:1.12-preview-rich-root:
+ (ネイティブ) rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)。
+
+:development:
+ (ネイティブ) 現在の開発フォーマット。
+ pack-0.92 (とpack-0.92と互換性のある)フォーマットリポジトリにデータを変換できます。
+ このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html
+ をご覧下さるようお願いします。
+
+
+:development-subtree:
+ (ネイティブ) 現在の開発フォーマット。サブツリーのバリアント。
+ pack-0.92-subtree (pack-0.92-subtreeと互換性のあるものなら何でも)フォーマットリポジトリ
+ から/へのデータの変換ができる。このフォーマットのリポジトリとブランチは
+ bzr.devによってのみ読み込みできます。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html
+ をご覧下さるようお願いします。
+
+
+廃止されたフォーマットは下記のとおりです。
+
+:metaweave:
+ (ネイティブ) 0.8の暫定的なフォーマット。knitよりも遅い
+
+:weave:
+ (ネイティブ) 0.8以前のフォーマット。knitよりも遅くチェックアウトと共用リポジトリをサポートしない。
+
+:knit:
+ (ネイティブ) knitを使用するフォーマット。0.14とそれ以前のbzrとの相互運用に推奨される。
+
+:dirstate:
+ (ネイティブ) 0.15での新しいフォーマット: ローカルオペレーションが速い。
+ ネットワークを通してアクセスするときは0.8とそれ以降のbzrと互換性がある。
+
+:dirstate-tags:
+ (ネイティブ) 0.15での新しいフォーマット: 速いローカルオペレーションとネットワークオペレーションに関する改善されたスケーリング。
+ タグ用のサポートを追加。0.15以前のbzrとは互換性がない
+
+:rich-root:
+ (ネイティブ) 1.0での新しいフォーマット。ツリーrootの扱いを改善。1.0以前のbzrと互換性がない。
+
+
+詳細なストレージフォーマットは ``bzr help formats`` を参照してください。
+
+
+リビジョンの識別子
+====================
+
+リビジョンの識別子はブランチの履歴の特定の状態を参照します。
+これはリビジョン番号、もしくは ':' が後に続くキーワード、と他のパラメータになります。
+識別子の例として '3' 、 'last:1' 、 'before:yesterday' と 'submit:' などがあります。
+
+'REV1' と 'REV2' がリビジョンの識別子である場合、
+'REV1..REV2' はリビジョンの範囲を表示します。
+例: '3647..3649' 、 'date:yesterday..-1' と 'branch:/path/to/branch1/..branch:/branch2'
+('..'周辺にはクォートもしくはスペースが存在しません)。
+
+範囲は異なるコマンドによって異なる解釈がなされます。
+"log" コマンドに対して、範囲はログメッセージのシーケンスで、
+"diff" コマンドに対しては、範囲は(変更のシーケンスではなく)リビジョン間の変更を表示します。
+加えて、 "log" はclosed rangeを考慮するのに対して"diff"と"merge"はopen-endedとみなす、
+すなわち、これらは1つのendを含みますが他方は含みません。
+例です: "bzr log -r 3647..3649"はリビジョン3647、3648と3649のメッセージを表示するのに対して、
+"bzr diff -r 3647..3649"は3647と3648の間に行われた変更を含み、3649の変更は含みません。
+
+リビジョン選択方法として使用されるキーワードは次のとおりです:
+
+:revno:
+ 番号を使用するリビジョンを選択する。
+:revid:
+ リビジョンidを使用するリビジョンを選択する。
+:last:
+ 最後からn番目のリビジョンを選択する。
+:before:
+ 指定されたリビジョンの親を選択する。
+:tag:
+ タグ名によって識別されるリビジョンを選択する。
+:date:
+ 日付スタンプを基本とするリビジョンを選択する。
+:ancestor:
+ 2番目のブランチで共通の祖先を選択する。
+:branch:
+ 指定ブランチの最終リビジョンを選択する。
+:submit:
+ 投稿ブランチで共通の祖先を選択する。
+
+加えて、プラグインは他のキーワードを提供できます。
+
+それぞれのキーワードの詳細な説明は下記のとおりです。
+
+:revno:
+
+ ブランチの履歴内のリビジョンを指定するために整数を使用する。
+ オプションとしてブランチを指定できます。接頭辞の 'revno:' はオプションです。
+ 負の数はブランチの最後から数えます(-1は最後のリビジョン、-2はその前のリビジョン)。
+ 負の数がブランチの履歴よりも大きい場合、最初のリビジョンが返されます。
+ 例::
+
+ revno:1 -> このブランチの最初のリビジョンを返す
+ revno:3:/path/to/branch -> '/path/to/branch' ブランチの3番目のリビジョンを返す
+ revno:-1 -> ブランチの最後のリビジョン。
+ -2:http://other/branch -> リモートブランチの最後から2番目のリビジョン。
+ -1000000 -> 履歴がとても長くなければ、おそらくは最初のリビジョン。
+
+:revid:
+
+ 特定のリビジョンidを提供します。
+ ブランチの祖先のリビジョンidを指定するために使用できます。
+ マージと、マージの追加を含む。
+ 例::
+
+ revid:aaaa@bbbb-123456789 -> リビジョン 'aaaa@bbbb-123456789' を選択する
+
+:last:
+
+ 最後からn番目のリビジョンを取得するには正の数を提供する。
+ 負の数の提供に関しては 'revno:' の仕様と同じです。
+ 例::
+
+ last:1 -> 最後のバージョンを返す。
+ last:3 -> 最後の2つ前のリビジョンを返す。
+
+:before:
+
+ そのリビジョンの親を返すリビジョンスペックを提供する。
+ 主にブランチのリビジョンの履歴の中に存在しないリビジョンを検査する際に便利です。
+
+ nullリビジョン(before:0)の親をリクエストするのは間違いです。
+
+ 例::
+
+ before:1913 -> revno 1913の親を返す (revno 1912)
+ before:revid:aaaa@bbbb-1234567890 -> リビジョンaaaa@bbbb-1234567890の親を返す
+ bzr diff -r before:1913..1913
+ -> リビジョン1913とその親(1912)の間の変更を見つける
+ (リビジョン1913が導入する変更が行うこと)。
+ これは bzr diff -c 1913と同等です
+
+:tag:
+
+ タグはブランチに保存され、'tag'コマンドによって作成される。
+
+:date:
+
+ 日付にマッチする最初のリビジョンを選択するためのデータスタンプを提供する。
+ 日付は 'yesterday'、'today'、'tomorrow' もしくはYYYY-MM-DDの文字列です。
+ 与えられた日付(深夜もしくは指定された時間のどちらか)の後の最初のエントリにマッチする。
+
+ 昨日以降のすべての変更を表示する方法の1つは次のとおりです::
+
+ bzr log -r date:yesterday..
+
+ 例::
+
+ date:yesterday -> 昨日以降の最初のリビジョンを選択する
+ date:2006-08-14,17:10:14 -> August 14th, 2006 at 5:10pmの後の最初のリビジョンを選択する。
+
+:ancestor:
+
+ 共通の祖先を選択するためにブランチへのパスを提供する。
+
+ 共通の祖先は両方のブランチの中に存在する最後のリビジョンです。
+ 通常これはブランチポイントですが、マージされたリビジョンにもなり得ます。
+
+ リモートブランチからマージしなかった変更を除外する一方で、
+ これはブランチが導入したすべての変更を返すために 'diff' でよく使用されます。
+
+ 例::
+
+ ancestor:/path/to/branch
+ $ bzr diff -r ancestor:../../mainline/branch
+
+:branch:
+
+ 最後のリビジョンを選択するためにブランチへのパスを提供する。
+
+ 例::
+
+ branch:/path/to/branch
+
+:submit:
+
+ これに対する差分は、このブランチで行われたすべての変更を表示し、
+ マージされる予定のもののよい予測子です。
+ 投稿ブランチはbundleとmergeコマンドによって使用されます。
+ 投稿ブランチが指定されなければ、親ブランチが代わりに使用されます。
+
+ 共通の祖先は両方のブランチ内に存在する最終リビジョンです。
+ 通常これはブランチポイントですが、マージされたリビジョンにもなり得ます。
+
+ 例::
+
+ $ bzr diff -r submit:
+
+
+標準オプション
+===============
+
+標準オプションはすべてのコマンドで有効です。
+
+--help, -h ヘルプメッセージを表示する。
+--verbose, -v 詳細な情報を表示する。
+--quiet, -q エラーと警告のみ表示する。
+
+グローバルオプションとは異なり、標準オプションはエイリアスで利用可能です。
+
+
+ステータスフラグ
+==================
+
+簡潔な方法で作業ツリーへの変更を要約するためにステータスフラグが使用されます。これらは次の形式をとります::
+
+ xxx <filename>
+
+カラムの意味は次のとおりです。
+カラム 1 - バージョン管理/リネーム::
+
+ + バージョン管理されているファイル
+ - バージョン管理されていないファイル
+ R リネームされたファイル
+ ? 未知のファイル
+ C 衝突した内容を持つファイル
+ P マージを追加するためのエントリ(ファイルではない)
+
+カラム 2 - コンテンツ::
+
+ N 作成されたファイル
+ D 削除されたファイル
+ K 変更されたファイルの種類
+ M 修正されたファイル
+
+カラム 3 - 実行::
+
+ * 実行が少し変更された
+
+
+URLの識別子
+============
+
+サポートされるURLの接頭辞::
+
+ aftp:// アクティブFTPを利用したアクセス
+ bzr:// Bazaarスマートサーバーを利用したファーストアクセス
+ bzr+ssh:// SSHを通したBazaarスマートサーバーを利用したファーストアクセス
+ file:// 標準ファイルシステムを利用したアクセス(デフォルト)
+ ftp:// パッシブFTPを利用したアクセス
+ http:// ウェブにエクスポートされたブランチへのリードオンリーのアクセス。
+ https:// SSLを利用したウェブにエクスポートされたブランチへのリードオンリーのアクセス。
+ sftp:// SFTPを利用したアクセス(大抵のSSHサーバーはSFTPを提供する)。
+
+
+.. _authentication: `認証の設定`_
+.. _bugs: `バグトラッカーの設定`_
+.. _configuration: `構成設定`_
+.. _conflicts: `衝突のタイプ`_
+.. _current-formats: `現在のストレージフォーマット`_
+.. _env-variables: `環境変数`_
+.. _global-options: `グローバルオプション`_
+.. _other-formats: `その他のストレージフォーマット`_
+.. _revisionspec: `リビジョンの識別子`_
+.. _standard-options: `標準オプション`_
+.. _status-flags: `ステータスフラグ`_
+.. _urlspec: `URLの識別子`_
+
+
+
+コマンド
+#########
+
+add
+===
+:目的: 指定したファイルもしくはディレクトリを追加する。
+:使い方: bzr add [FILE...]
+
+:オプション:
+ --dry-run 何が行われるか表示するが、実際には行わない。
+ -v, --verbose 詳細な情報を表示する。
+ --no-recurse ディレクトリの内容を再帰的に追加しない。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ --file-ids-from=ARG このツリーからファイルのidを探索する。
+
+:説明:
+ non-recursiveモードでは、以前無視されたファイルであっても、
+ 名前つきのすべてのアイテムが追加されます。
+ 名前つきファイルがすでにバージョン管理されている場合は警告が表示されます。
+
+ recursiveモード(デフォルト)では、ファイルは同じ方法で扱われますが、
+ ディレクトリに対するふるまいは異なります。
+ すでにバージョン管理されているディレクトリであれば警告は表示されません。
+ すべてのディレクトリは、バージョン管理されているかいないかに関わらず、
+ ファイルもしくはバージョン管理も無視もされているサブディレクトリのための検索対象になり、
+ これらは追加されます。
+ この検索はバージョン管理されたディレクトリにも再帰的に進められます。
+ 名前が渡されなければ、'.'が想定されます。
+
+ それゆえ単に 'bzr add' を実行すると現在未知であるファイルのすべてがバージョン管理されます。
+
+ 親ディレクトリがバージョン管理されていないファイルを追加すると
+ 親およびそのrootまでも暗黙の内に追加されます。
+ このことが意味するのはディレクトリを明示的に追加する必要はなく、
+ ディレクトリの中のファイルを1つ追加するときにそれらのディレクトリも追加されます。
+
+ --dry-runは追加されるファイルを表示しますが、それらを実際に追加しません。
+
+ --file-ids-fromは提供されたパスからファイルのidの使用を試みます。
+ これは同じファイル名を持ちマッチするディレクトリの発見をするためにidを探し、また純粋なパスによって行います。
+ このオプションが必要になるのはめったにありませんが、後でマージする2つのブランチに同じ論理ファイルを追加する
+ ときに便利です(2つの異なる追加を衝突として表示しません)。
+ 別のプロジェクトをこのプロジェクトのサブディレクトリにマージする際にも便利です。
+
+:関連コマンド: `remove`_
+
+
+alias
+=====
+:目的: エイリアスの設定/設定解除と表示を行う。
+:使い方: bzr alias [NAME]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ --remove エイリアスを削除する。
+ -h, --help ヘルプメッセージを表示する。
+
+:例:
+ 現在のエイリアスを表示するには::
+
+ bzr alias
+
+ 'll'用に指定されたエイリアスを表示するには::
+
+ bzr alias ll
+
+ 'll'のエイリアスを設定するには::
+
+ bzr alias ll="log --line -r-10..-1"
+
+ 'll'のエイリアスを削除するには::
+
+ bzr alias --remove ll
+
+
+
+annotate
+========
+:目的: ファイルのそれぞれの行のoriginを表示する。
+:使い方: bzr annotate FILENAME
+
+:オプション:
+ --all すべての行の注釈を表示する。
+ -v, --verbose 詳細な情報を表示する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --long 注釈のコミット日時を表示する。
+ --show-ids 内部のオブジェクトidを表示する。
+ -r ARG, --revision=ARG
+ "help revisionspec"の詳細を参照。
+
+:説明:
+ このコマンドは与えられたファイルの、変更によって導入されたリビジョン、
+ 筆者と日付を示す注釈を左側で表示します。
+
+ 連続した行の続きに関してoriginが同じ場合、
+ --allオプションが渡されない限り、これはトップでのみ表示されます。
+
+:エイリアス: ann, blame, praise
+
+
+bind
+====
+:目的: 現在のブランチを提供されたブランチのチェックアウトに変換する。
+:使い方: bzr bind [LOCATION]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ チェックアウトに変換されると、コミットはローカルブランチに適用される前に
+ コミットはマスターブランチを継承しなければなりません。
+
+ ローカルに設定されない限りバインドされたブランチは
+ マスターブランチのニックネームを使用します。
+ この場合、バインディングはローカルなニックネームをマスターのものに更新します。
+
+:関連コマンド: `checkout`_, `unbind`_
+
+
+branch
+======
+:目的: ブランチの新しいコピーを作成する。
+:使い方: bzr branch FROM_LOCATION [TO_LOCATION]
+
+:オプション:
+ --stacked ソースブランチを参照するスタックドブランチを作成する。
+ すべてのオペレーションに関して
+ 新しいブランチはソースブランチの利用可能性に依存する。
+ -v, --verbose 詳細な情報を表示する。
+ --standalone 利用可能であっても共用リポジトリを使用しない。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --hardlink 可能な作業ツリーファイルをハードリンクする。
+ -r ARG, --revision=ARG
+ 詳細は "help revisionspec" を参照。
+
+:説明:
+ TO_LOCATIONが省略されると、FROM_LOCATIONの最終コンポーネントが使用されます。
+ 言い換えると、 "branch ../foo/bar" は./bar を作成しようとします。
+ FROM_LOCATIONが/を持たない もしくは埋め込みのパスの区切り文字を持つ場合
+ 冒頭のスキームもしくはドライブの識別子を剥ぎ取ることで、
+ FROM_LOCATIONからTO_LOCATIONが得られます。
+ たとえば、"branch lp:foo-bar"は./foo-barを作成しようとします。
+
+ ブランチの特定のリビジョンを読み取るには、
+ "branch foo/bar -r 5"のような、--revisionパラメータを提供します。
+
+:エイリアス: get, clone
+:関連コマンド: `checkout`_
+
+
+break-lock
+==========
+:目的: リポジトリ、ブランチもしくは作業ディレクトリのデッドロックをブレークする。
+:使い方: bzr break-lock [LOCATION]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 警告: ロックを保持するプロセスが停止したときにのみロックはブレークします。
+
+ 'bzr info'コマンドを通して開いているロックに関する情報を得ることができます。
+
+:例:
+ bzr break-lock
+
+
+
+cat
+===
+:目的: 与えられたリビジョンのファイルの内容を標準出力に書き込む。
+:使い方: bzr cat FILENAME
+
+:オプション:
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --name-from-revision 古いツリーのパス名。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ リビジョンが指定されなければ、最後のリビジョンが使用されます。
+
+ 注意: バイナリファイルでこのコマンドを使用する際には
+ 標準出力をリダイレクトするように気をつけてください。
+
+:関連コマンド: `ls`_
+
+
+check
+=====
+:目的: 作業ツリーの構造、ブランチの一貫性、とリポジトリの履歴をバリデートする。
+:使い方: bzr check [PATH]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ --tree 現在のディレクトリに関連した作業ツリーをチェックする。
+ -q, --quiet エラーと警告だけ表示する。
+ --repo 現在のディレクトリに関連したリポジトリをチェックする。
+ --branch 現在のディレクトリに関連したブランチをチェックする。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ このコマンドはデータの破損もしくはbzrのバグを検出するために
+ ブランチとリポジトリストレージに関するさまざまな不変量をチェックします・
+
+ 問題が検出された場合のみ作業ツリーとブランチのチェックは出力をします。
+ リポジトリチェックの出力フィールドは次のとおりです:
+
+ revisions: これはチェックされるリビジョンの番号です。
+ これは問題を示しません。
+ versionedfiles: これはチェックされるバージョン管理されたファイルの数です。
+ これは問題を示しません。
+ unreferenced ancestors: 他のテキストの祖先であるテキストは、
+ リビジョンの祖先によって適切に参照されません。
+ これはBazaarが対処できるsubtleな問題です。
+ unique file texts: チェックされるリビジョンで見つかる
+ ファイルの内容の合計数です。これは問題を示しません。
+ repeated file texts: チェックされるリビジョンで見つかる、
+ 繰り返されるテキストの合計数です。
+ テキストのエントリが修正されたときにテキストは繰り返しできますが、
+ ファイルの内容は繰り返しできません。
+ これは問題を示しません。
+
+ 制限が指定されなければ、すべてのBazaarデータはチェックされる位置で見つかります。
+
+:例:
+ 'foo' でのツリーとブランチをチェックする::
+
+ bzr check --tree --branch foo
+
+ 'bar'でのリポジトリのみをチェックする::
+
+ bzr check --repo bar
+
+ 'baz' ですべてをチェックする::
+
+ bzr check baz
+
+:関連コマンド: `reconcile`_
+
+
+checkout
+========
+:目的: 既存のブランチの新しいチェックアウトを作成する。
+:使い方: bzr checkout [BRANCH_LOCATION] [TO_LOCATION]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -h, --help ヘルプメッセージを表示する。
+ --files-from=ARG このツリーからファイルの内容を取得する。
+ -q, --quiet エラーと警告のみを表示する。
+ --hardlink 利用可能な作業ツリーファイルをハードリンクする。
+ --lightweight 軽量チェックアウトを実行する。オペレーションに関して
+ 軽量チェックアウトはブランチへの権限に依存する。
+ 通常のチェックアウトはdiffやstatusのようなアクセスが
+ 不要な共通のオペレーションを実行可能で、
+ ローカルコミットもサポートします。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:説明:
+ BRANCH_LOCATIONが省略されると、'.'で見つかるブランチ用に
+ チェックアウトは作業ツリーを再構成します。
+ 作業ツリーを削除した場合もしくはこれがけっして作成されない場合
+ - すなわち、SFTPを使用してブランチを現在の位置にpushする場合、これは便利です。
+
+ TO_LOCATIONが省略されると、BRANCH_LOCATIONの最後のコンポーネントが使用されます。
+ 言い換えると、"checkout ../foo/bar" は./barを作成しようとします。
+ BRANCH_LOCATIONが has no /を持たないもしくはパスの区切り文字が埋め込まれている場合、
+ 先頭のスキームもしくはドライブの識別子を除去することでBRANCH_LOCATIONからTO_LOCATIONが
+ 得られます。たとえば、"checkout lp:foo-bar"は./foo-barを作成しようとします。
+
+ 特定のリビジョンのブランチを読み取るには、
+ "checkout foo/bar -r 5"のように--revisionパラメータを提供します。
+ これはすぐに時代遅れになりますが[なのでコミットできない]
+ 役に立つことがあります(すなわち古いコードを検査するため)。
+
+:エイリアス: co
+:関連コマンド: `branch`_, `チェックアウト`_
+
+
+commit
+======
+:目的: 変更を新しいリビジョンにコミットする。
+:使い方: bzr commit [SELECTED...]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ --author=ARG 著者の名前がコミッターとは異なる場合、著者の名前を設定する。
+ --unchanged 何も変更されていなくてもコミットする。
+ --fixes=ARG このリビジョンをバグが修正されたものとしてマークする。
+ -q, --quiet エラーと警告のみを表示する。
+ --show-diff メッセージが提供されないとき、
+ メッセージエディタでステータスの要約と一緒に差分を表示する。
+ --strict 作業ツリーの中に未知のファイルが存在する場合コミットを拒否する。
+ -F MSGFILE, --file=MSGFILE
+ このファイルからコミットメッセージを取得する。
+ -x ARG, --exclude=ARG
+ 与えられたパスへの変更を考慮しない。
+ -m ARG, --message=ARG
+ 新しいリビジョンの説明。
+ --local バインドされたブランチにローカルコミットを実行する。
+ 通常のコミットが実行されるまで
+ ローカルコミットはマスターブランチにpushされません。
+
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 引数が渡されなければ、ツリー全体がコミットされます。
+
+ 選択されたファイルが指定されると、これらのファイルへの変更のみがコミットされます。
+ ディレクトリが指定されるとディレクトリとその中のすべてがコミットされます。
+
+ excludesが渡されるとき、これらは選択されたファイルよりも優先されます。
+ たとえば、fooの範囲での変更のみコミットされますが、foo/barの範囲の変更はコミットされません::
+
+ bzr commit foo -x foo/bar
+
+ 変更の著者がコミッターと同じ人物でなければ、
+ --authorオプションを使用して著者の名前を指定できます。
+ 名前はコミッターidと同じフォーマットです。たとえば"John Doe <jdoe@example.com>"です。
+
+ コミットされるツリーが無効である場合選択されたファイルのコミットが失敗することがあります。
+ 次の一連のコマンドを考えてみましょう::
+
+ bzr init foo
+ mkdir foo/bar
+ bzr add foo/bar
+ bzr commit foo -m "committing foo"
+ bzr mv foo/bar foo/baz
+ mkdir foo/bar
+ bzr add foo/bar
+ bzr commit foo/bar -m "committing bar but not baz"
+
+ 上記の例において、最終コミットは故意に失敗します。
+ これによってユーザーは、同時に、最初に個別に、もしくはまったく
+ リネームしたくないかどうかを決める機会を得ます。
+ (一般的なルールとして、判断がつかないとき、Bazaarは安全に物事を行う方針を持ちます。)
+
+ 注: マージの後の選択されたファイルのコミットはまだサポートされていません。
+
+:エイリアス: ci, checkin
+:関連コマンド: `bugs`_, `uncommit`_
+
+
+conflicts
+=========
+:目的: 衝突を持つファイルの一覧を表示する。
+:使い方: bzr conflicts
+
+:オプション:
+ --text テキストの衝突を持つファイルのパスの一覧を表示する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ マージは2つのブランチの変更を結合するために最善を尽くしますが、
+ 人間だけが修正できるある種の問題が存在します。
+ この問題に遭遇するとき、衝突がマークされます。
+ 衝突はコミットする前に何かを修正する必要があることを意味します。
+
+ 通常の衝突は短く人間が読めるメッセージとして一覧が示されます。
+ --textが提供される場合、代わりに、テキストの衝突を持つファイルのパスの一覧が表示されます。
+ (これはテキストの衝突を持つファイルをすべて編集するために便利です。)
+
+ 問題を修正したらbzr resolveを使用します。
+
+:関連コマンド: `resolve`_
+
+
+
+deleted
+=======
+:目的: 作業ツリーの中で削除されたファイルの一覧を表示する。
+:使い方: bzr deleted
+
+:オプション:
+ --show-ids 内部のオブジェクトidを表示する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:関連コマンド: `ls`_, `status`_
+
+
+diff
+====
+:目的: リビジョンもしくはブランチの間の、作業ツリーの中の違いを表示する。
+:使い方: bzr diff [FILE...]
+
+:オプション:
+ --old=ARG から比較するブランチ/ツリー。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -p ARG, --prefix=ARG コロンによって区切られた2つの値として
+ 新旧のファイル名に追加される接頭辞を設定する(たとえば"old/:new/")。
+ --using=ARG ファイルを比較するためにこのコマンドを使用する。
+ --new=ARG へ比較するブランチ/ツリー。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+ --diff-options=ARG これらのオプションを外部diffプログラムに渡す。
+ -c ARG, --change=ARG 指定されたリビジョンによって導入された変更を選択する。
+ "help revisionspec"も参照。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 引数が渡されなければ、現在のツリーに対するすべての変更の一覧が表示されます。
+ ファイルが渡されれば、これらのファイルの中の変更の一覧だけが表示されます。
+ リモートと複数のブランチは--oldと--newオプションを使用して比較できます。
+ これらのオプションが提供されなければ、両方のデフォルトは、存在すれば最初の引数、
+ 引数が渡されなければ現在のツリーから得られます。
+
+ "bzr diff -p1" は "bzr diff --prefix old/:new/"と同等で、
+ "patch -p1"に最適なパッチが生成されます。
+
+:例:
+ 作業ツリーと最終コミットの間の違いを表示する::
+
+ bzr diff
+
+ 作業ツリーとリビジョン1の間の違い::
+
+ bzr diff -r1
+
+ リビジョン1とリビジョン2の間の違い::
+
+ bzr diff -r1..2
+
+ ブランチxxxのリビジョン1とリビジョン2の間の違い::
+
+ bzr diff -r1..2 xxx
+
+ NEWSファイルの違いだけ表示する::
+
+ bzr diff NEWS
+
+ NEWSファイルに対する作業ツリーの中の違いを表示する::
+
+ bzr diff xxx/NEWS
+
+ xxxブランチからこの作業ツリーの違いを表示する:
+
+ bzr diff --old xxx
+
+ NEWSファイルに対する2つのブランチの違いを表示する::
+
+ bzr diff --old xxx --new yyy NEWS
+
+ 'bzr diff'と同じであるがold/とnew/でパスに接頭辞を追加する::
+
+ bzr diff --prefix old/:new/
+
+:Exitの値:
+ 1 - 変更された
+ 2 - 表現できない変更
+ 3 - エラー
+ 0 - 変更なし
+
+
+:エイリアス: di, dif
+:関連コマンド: `status`_
+
+
+export
+======
+:目的: 現在のリビジョンを指定されたディレクトリもしくはアーカイブにエクスポートする。
+:使い方: bzr export DEST [BRANCH_OR_SUBDIR]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ --format=ARG Type of file to export to.
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --root=ARG エクスポートされたファイル内部のrootディレクトリの名前。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:説明:
+ リビジョンが指定されなければこれは最終コミットのリビジョンをエクスポートします。
+
+ フォーマットはtar、tgz、tbz2のような"exporter"の名前になることができます。
+ 何も渡されなければ、拡張子かrフォーマットを見つけようとします。
+ 拡張子が見つからなければディレクトリにエクスポートします(--format=dirと同等)。
+
+ rootが提供されると、これはコンテナフォーマット(tar、zip、その他)内部のrootディレクトリとして使用されます。
+ これが提供されなければエクスポートされるファイル名へのデフォルトになります。
+ rootオプションは'dir'フォーマットに対して効果がありません。
+
+ ブランチが省略されると現在の作業ディレクトリを含むブランチが使用されます。
+
+ 注: ASCIIではないファイル名でのツリーのエクスポートはサポートされません。
+
+ ========================== =========================
+ サポートされるフォーマット 拡張子で自動検出
+ ========================== =========================
+ dir (none)
+ tar .tar
+ tbz2 .tar.bz2, .tbz2
+ tgz .tar.gz, .tgz
+ zip .zip
+ ========================== =========================
+
+
+
+help
+====
+:目的: コマンドもしくは他のトピックのヘルプを表示する。
+:使い方: bzr help [TOPIC]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ --long すべてのコマンドのヘルプを表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:エイリアス: ?, --help, -?, -h
+:関連コマンド: topics
+
+
+ignore
+======
+:目的: 指定されたファイルもしくはパターンを無視する。
+:使い方: bzr ignore [NAME_PATTERN...]
+
+:オプション:
+ --old-default-rules bzr < 0.9で使用される無視ルールを書き出す。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ パターンの構文の詳細は ``bzr help patterns`` を参照。
+
+ 無視リストからパターンを除外するには、.bzrignoreファイルを編集します。
+ 追加した後で、コマンドを使用して間接的に、もしくはエディタを使用して
+ 直接そのファイルを編集もしくは削除した後で、そのコミットを確認してください。
+
+ 注: シェルのワイルドカードを含む無視パターンはUnixのシェルからクォートされなければなりません。
+
+:例:
+ トップレベルのMakefileを無視する::
+
+ bzr ignore ./Makefile
+
+ すべてのディレクトリのクラスファイルを無視する::
+
+ bzr ignore "*.class"
+
+ libディレクトリ下の.oファイルを無視する::
+
+ bzr ignore "lib/**/*.o"
+
+ libディレクトリ下の.oファイルを無視する::
+
+ bzr ignore "RE:lib/.*\.o"
+
+ "debian"トップレベルディレクトリ以外のすべてを無視する::
+
+ bzr ignore "RE:(?!debian/).*"
+
+:関連コマンド: `ignored`_, `パターン`_, `status`_
+
+
+ignored
+=======
+:目的: 無視するファイルとそれらにマッチするパターンの一覧を表示する。
+:使い方: bzr ignored
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 無視されるファイルと無視パターンのすべての一覧を表示します。
+
+ 代わりにファイルの一覧だけを表示するには::
+
+ bzr ls --ignored
+
+:関連コマンド: `ignore`_, `ls`_
+
+
+info
+====
+:目的: 作業ツリー、ブランチもしくはリポジトリに関する情報を表示する。
+:使い方: bzr info [LOCATION]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ このコマンドはツリー、ブランチもしくはリポジトリに関連する既知の位置とフォーマットのすべてを表示します。
+ 統計情報はそれぞれのレポートに含まれます。
+
+ ブランチと作業ツリーは見つからないリビジョンもレポートします。
+
+:関連項目: `リポジトリ`_, `revno`_, `作業ツリー`_
+
+
+init
+====
+:目的: ディレクトリをバージョン管理下にあるブランチにする。
+:使い方: bzr init [LOCATION]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ --create-prefix ブランチに通じるパスがまだ存在していなければそれを作成する。
+ --append-revisions-only
+ revnosもしくは既存のログを変更しない。
+ リビジョンを追加するのみ。
+ -q, --quiet エラーと警告のみを表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+ ブランチのフォーマット::
+
+ --format=ARG このブランチのフォーマットを指定する。"help formats"を参照。
+ --1.12-preview ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
+ --1.12-preview-rich-root
+ rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)
+ --1.6 スタックをサポートするリポジトリに基づいたブランチとパック。
+ --1.6.1-rich-root スタックとリッチなrootデータをサポートするリポジトリに基づいた
+ ブランチとパック(bzr-svnに必要)。
+ --1.9 btreeインデックスを使用するリポジトリに基づいたブランチとパック
+ --1.9-rich-root btreeインデックスとリッチrootデータを使用する
+ リポジトリに基づいたブランチとパック(bzr-svnに必要)。
+ --default 0.92の新しい機能: dirstate-tagsフォーマットリポジトリと
+ 互換性のあるデータを持つパックベースのフォーマット。
+ 0.92以前のbzrリポジトリと相互運用しますが
+ bzr < 0.92では読むことができません。
+ 以前はknitpack-experimentalと呼ばれていました。
+ 詳細な情報は http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
+ --development 現在の開発フォーマット。データをpack-0.92 (とpack-0.92と互換性のある)
+ フォーマットリポジトリに変換できる。
+ このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html を参照して頂くようお願いします。
+ --development-subtree
+ 現在の開発フォーマットで、subtreeバリアント。
+ データをpack-0.92-subtree(とpack-0.92-subtreeと互換性のある)
+ フォーマットリポジトリに変換できる。
+ このフォーマットのリポジトリとブランチはbzr.devでのみ読み込みできる。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-
+ repo.html をご覧いただくようお願いします。
+ --dirstate 0.15の新しいフォーマット: 速いローカルオペレーション。
+ ネットワークを通したアクセスのときbzr 0.8とそれ以降と互換性がある。
+ --dirstate-tags 0.15の新しいフォーマット: 速いローカルオペレーションで
+ ネットワークオペレーションに関するスケーリングを改善。
+ タグのサポートを追加。bzr < 0.15とは互換性がない。
+ --knit knitsを使用するフォーマット。bzr <= 0.14との相互運用に推奨。
+ --metaweave 0.8での暫定フォーマット。knitよりも遅い。
+ --pack-0.92 0.92の新しいフォーマット: dirstate-tagsフォーマットリポジトリと
+ 互換性のあるデータを持つパックベースのフォーマット。
+ 0.92以前のbzrリポジトリと相互運用できるがbzr < 0.92.によって読み込みできない。
+ 以前はknitpack-experimentalと呼ばれていた。
+ 詳細な情報に関しては、 http://doc
+ .bazaar-vcs.org/latest/developers/packrepo.html を参照。
+ --rich-root 1.0の新しいフォーマット。ツリーrootのベターな扱い。
+ bzr < 1.0と互換性がない。
+ --rich-root-pack 1.0の新しいフォーマット: rich-rootデータをサポートする
+ pack-0.92のバリアント(bzr-svnに必要)。
+ --weave 0.8以前のフォーマット。knitよりも遅く
+ チェックアウトもしくは共用リポジトリをサポートしない。
+
+:説明:
+ 空のブランチを作成するもしくは既存のプロジェクトをインポートする前に使用します。
+
+ 親ディレクトリの位置にリポジトリが存在する場合、
+ ブランチの履歴はリポジトリに保存されます。
+ さもなければinitは.bzrのディレクトリに独自の履歴を運ぶスタンドアロンのブランチを作成します。
+
+ ロケーションにブランチがすでにあるが作業ツリーがない場合、ツリーは'bzr checkout'で投入できます。
+
+ ファイルのツリーをインポートする方法のレシピです::
+
+ cd ~/project
+ bzr init
+ bzr add .
+ bzr status
+ bzr commit -m "imported project"
+
+:関連コマンド: `branch`_, `checkout`_, `init-repository`_
+
+
+init-repository
+===============
+:目的: ブランチを保持する共用リポジトリを作成する。
+:使い方: bzr init-repository LOCATION
+
+:オプション:
+ --no-trees リポジトリのブランチはデフォルトで作業ツリーを持ちません。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+ ブランチのフォーマット::
+
+ --format=ARG このブランチのフォーマットを指定する。"help formats"を参照。
+ --1.12-preview ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
+ --1.12-preview-rich-root
+ rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)
+ --1.6 スタックをサポートするリポジトリに基づいたブランチとパック。
+ --1.6.1-rich-root スタックとリッチなrootデータをサポートするリポジトリに基づいた
+ ブランチとパック(bzr-svnに必要)。
+ --1.9 btreeインデックスを使用するリポジトリに基づいたブランチとパック
+ --1.9-rich-root btreeインデックスとリッチrootデータを使用する
+ リポジトリに基づいたブランチとパック(bzr-svnに必要)。
+ --default 0.92の新しい機能: dirstate-tagsフォーマットリポジトリと
+ 互換性のあるデータを持つパックベースのフォーマット。
+ 0.92以前のbzrリポジトリと相互運用しますが
+ bzr < 0.92では読むことができません。
+ 以前はknitpack-experimentalと呼ばれていました。
+ 詳細な情報は http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
+ --development 現在の開発フォーマット。データをpack-0.92 (とpack-0.92と互換性のある)
+ フォーマットリポジトリに変換できる。
+ このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html を参照して頂くようお願いします。
+ --development-subtree
+ 現在の開発フォーマットで、subtreeバリアント。
+ データをpack-0.92-subtree(とpack-0.92-subtreeと互換性のある)
+ フォーマットリポジトリに変換できる。
+ このフォーマットのリポジトリとブランチはbzr.devでのみ読み込みできる。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-
+ repo.html をご覧いただくようお願いします。
+ --dirstate 0.15の新しいフォーマット: 速いローカルオペレーション。
+ ネットワークを通したアクセスのときbzr 0.8とそれ以降と互換性がある。
+ --dirstate-tags 0.15の新しいフォーマット: 速いローカルオペレーションで
+ ネットワークオペレーションに関するスケーリングを改善。
+ タグのサポートを追加。bzr < 0.15とは互換性がない。
+ --knit knitsを使用するフォーマット。bzr <= 0.14との相互運用に推奨。
+ --metaweave 0.8での暫定フォーマット。knitよりも遅い。
+ --pack-0.92 0.92の新しいフォーマット: dirstate-tagsフォーマットリポジトリと
+ 互換性のあるデータを持つパックベースのフォーマット。
+ 0.92以前のbzrリポジトリと相互運用できるがbzr < 0.92.によって読み込みできない。
+ 以前はknitpack-experimentalと呼ばれていた。
+ 詳細な情報に関しては、 http://doc
+ .bazaar-vcs.org/latest/developers/packrepo.html を参照。
+ --rich-root 1.0の新しいフォーマット。ツリーrootのベターな扱い。
+ bzr < 1.0と互換性がない。
+ --rich-root-pack 1.0の新しいフォーマット: rich-rootデータをサポートする
+ pack-0.92のバリアント(bzr-svnに必要)。
+ --weave 0.8以前のフォーマット。knitよりも遅く
+ チェックアウトもしくは共用リポジトリをサポートしない。
+
+:説明:
+ ブランチのディレクトリではなく、リポジトリにリビジョンを保存する
+ リポジトリディレクトリの元で作成された新しいブランチ。
+
+ --no-treesオプションが使用されるとリポジトリのブランチはデフォルトで作業ツリーを持ちません。
+
+:例:
+ ブランチだけを保有する共用リポジトリを作成する::
+
+ bzr init-repo --no-trees repo
+ bzr init repo/trunk
+
+ 軽量チェックアウトを作成する::
+
+ bzr checkout --lightweight repo/trunk trunk-checkout
+ cd trunk-checkout
+ (add files here)
+
+:エイリアス: init-repo
+:関連項目: `branch`_, `checkout`_, `init`_, `リポジトリ`_
+
+
+log
+===
+:目的: ブランチ、ファイル、もしくはディレクトリのログを表示する。
+:使い方: bzr log [LOCATION]
+
+:オプション:
+ -v, --verbose それぞれのリビジョンで変更されたファイルを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -l N, --limit=N 出力を最初のNのリビジョンに制限する。
+ --forward 最古から最新までを表示する。
+ --timezone=ARG ローカル、オリジナル、utcのタイムゾーンを表示する。
+ --show-ids 内部オブジェクトidを表示する。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+ -m ARG, --message=ARG
+ メッセージが正規表現にマッチするリビジョンを表示する。
+ -c ARG, --change=ARG 指定されたリビジョンだけを表示する。"help revisionspec"も参照。
+ -h, --help ヘルプメッセージを表示する。
+
+ ログのフォーマット::
+ --log-format=ARG 指定されたログフォーマットを使用する。
+ --line リビジョン単位の1行のログフォーマット
+ --long 詳細なログフォーマット
+ --short 適切に短いログフォーマット
+
+:説明:
+ デフォルトでは作業ディレクトリを含むブランチのログを表示する。
+
+ ログの範囲をリクエストするには、-r begin..endコマンドを使用できます。
+ -r revisionは指定したリビジョンをリクエストし、
+ -r ..end もしくは -r begin.. も有効です。
+
+:例:
+ 現在のブランチのログ::
+
+ bzr log
+
+ ファイルのログ::
+
+ bzr log foo.c
+
+ ブランチの最後の10リビジョンのログ::
+
+ bzr log -r -10.. http://server/branch
+
+
+
+ls
+==
+:目的: ツリーのファイルの一覧を表示する。
+:使い方: bzr ls [PATH]
+
+:オプション:
+ --from-root ブランチのrootから相対的なパスを出力する。
+ --ignored 無視されたファイルを出力する。
+ --kind=ARG 特定の種類:file、directory、symlinkのエントリの一覧を表示する。
+ -v, --verbose 詳細な情報を表示する。
+ -V, --versioned バージョン管理されたファイルを出力する。
+ --unknown 未知のファイルを出力する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --non-recursive サブディレクトリで再帰的処理を行わない。
+ --show-ids 内部オブジェクトidを表示する。
+ --null ファイルの間に改行の代わりに NUL (\0) 区切り文字を書く。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:関連項目: `cat`_, `status`_
+
+
+merge
+=====
+:目的: 三方向マージを実行する。
+:使い方: bzr merge [LOCATION]
+
+:オプション:
+ --pull すでに対象が完全にソースにマージされる場合、
+ マージよりもソースからpullする。
+ これが起きるとき、結果をコミットする必要はない。
+ --remember 指定されたロケーションをデフォルトとして記録する。
+ --force 目的のツリーがコミットされていない変更を持っていてもマージする。
+ -v, --verbose 詳細な情報を表示する。
+ --reprocess 誤った衝突を減らすために再処理する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --uncommitted ブランチの変更の代わりに、作業ツリーからコミットされていない変更を適用する。
+
+ -d ARG, --directory=ARG
+ 作業ディレクトリを含むものよりも、マージするブランチ。
+ --show-base 衝突のベースリビジョンテキストを表示する。
+ --preview マージする代わりに、マージの差分を表示する。
+ -c ARG, --change=ARG 指定されたリビジョンで導入された変更を選択する。
+ "help revisionspec"も参照。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+ マージアルゴリズム::
+ --merge-type=ARG 特定のマージアルゴリズムを選択する。
+ --diff3 外部diff3を使用するマージ
+ --lca 新しいLCAマージ
+ --merge3 ネイティブのdiff3スタイルのマージ
+ --weave weaveベースのマージ
+
+:説明:
+ マージのソースはブランチの形式、もしくはbzr sendで生成された
+ mergeディレクティブを含むファイルへのパスの形式で指定できます。
+ どちらも指定されなければ、デフォルトは上流ブランチもしくは
+ --rememberを使用して最近マージされたブランチです。
+
+ マージをブランチするとき、デフォルトではチップがマージされます。
+ 異なるリビジョンをピックするには、--revisionを渡します。
+ 2つの値を指定する場合、最初の値はBASEとして、2番目の値はOTHERとして使用されます。
+ 個別のリビジョン、もしくはこのように利用可能なリビジョンのサブセットをマージすることは
+ 一般的に"チェリーピック"として言及されます。
+
+ リビジョン番号はマージされるブランチに対して常に相対的です。
+
+ デフォルトでは、bzrは、自動的に適切なベースを検出して、
+ 他のブランチからすべてのネットワークでマージしようとします。
+ これが失敗すると、明示的なベースを渡すことが必要になることがあります。
+
+ マージは2つのブランチの変更を結合するために最善を尽くしますが、
+ 人間だけが修正できる種類の問題があります。
+ この問題に遭遇するとき、衝突マークがつけられます。
+ 衝突はコミットする前に何かを修正する必要があることを意味します。
+
+ 問題を修正したらbzr resolveを使用します。bzr conflictsも参照してください。
+
+ デフォルトのブランチセットが存在しない場合、最初のマージはそれを設定します。
+ その後で、デフォルトを使用するブランチを省略できます。
+ デフォルトを変更するには、--rememberを使用します。
+ リモートロケーションがアクセス可能場合のみ値は保存されます。
+
+ マージの結果は目的の作業ディレクトリに設置されます。
+ このディレクトリは(bzr diffで)閲覧、テスト、
+ とマージの結果を記録するためにコミット可能です。
+
+ --forceが渡されない限り、コミットされていない変更が存在すればマージの実行は拒否されます。
+
+:例:
+ bzr.devから最新のリビジョンをマージするには::
+
+ bzr merge ../bzr.dev
+
+ bzr.devからリビジョン82を含めて変更をマージするには::
+
+ bzr merge -r 82 ../bzr.dev
+
+ 以前の変更なしに、82で導入された変更をマージするには::
+
+ bzr merge -r 81..82 ../bzr.dev
+
+ /tmp/mergeに含まれるmergeディレクトリを適用するには:
+
+ bzr merge /tmp/merge
+
+:関連項目: `remerge`_, `status-flags`_, `update`_
+
+
+missing
+=======
+:目的: 2つのブランチの間のmergeされていない/pullされていない リビジョンを表示する。
+:使い方: bzr missing [OTHER_BRANCH]
+
+:オプション:
+ --reverse リビジョンの順序をリバースする。
+ --this --mine-onlyと同じ。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ --other --theirs-onlyと同じ。
+ --include-merges マージされたリビジョンを表示する。
+ --mine-only ローカルブランチの変更のみを表示する。
+ --show-ids 内部オブジェクトidを表示する。
+ --theirs-only リモートブランチの変更のみを表示する。
+ -v, --verbose 詳細な情報を表示する。
+
+ ログフォーマット::
+ --log-format=ARG 指定したログフォーマットを使用する。
+ --line リビジョンごとの1行のログフォーマット
+ --long 詳細なログフォーマット
+ --short 適切に短いログフォーマット
+
+:説明:
+ OTHER_BRANCHはlocalもしくはremoteになります。
+
+:関連項目: `merge`_, `pull`_
+
+
+mkdir
+=====
+:目的: バージョン管理下にある新しいディレクトリを作成する。
+:使い方: bzr mkdir DIR...
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ これはディレクトリの作成と追加と同等です。
+
+
+
+mv
+==
+:目的: ファイルを移動もしくはリネームする。
+:使い方:
+ bzr mv OLDNAME NEWNAME
+
+ bzr mv SOURCE... DESTINATION
+
+
+:オプション:
+ --after ファイルがすでに移動しているので、ファイルのbzr識別子のみを移動させる。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 最後の引数がバージョン管理されているディレクトリの場合、
+ 他のすべての名前はそこに移動します。
+ さもなければ、2つの引数だけにしなければならず
+ ファイルは新しい名前に変更されます。
+
+ OLDNAMEがファイルシステム上に存在しないがバージョン管理されていて
+ NEWNAMEはファイルシステム上に存在せずバージョン管理もされていない場合、
+ mvはファイルが手動で移動させられその変更を反映するために
+ 内部インベントリだけを更新することを想定します。
+ 多くのSOURCEファイルをDESTINATIONに移動させるときも同じです。
+
+ ブランチの間でファイルを移動させることはできません。
+
+:エイリアス: move, rename
+
+
+nick
+====
+:目的: ブランチのニックネームを表示もしくは設定する。
+:使い方: bzr nick [NICKNAME]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 設定が解除されると、ツリーのrootディレクトリの名前がニックネームとして使用されます。
+ 現在のニックネームを表示するには、引数なしで実行します。
+
+ ローカルに設定されていない限りバインドされたブランチはマスターブランチのニックネームを使用します。
+
+:関連コマンド: `info`_
+
+
+pack
+====
+:目的: リポジトリ内のデータを圧縮する。
+:使い方: bzr pack [BRANCH_OR_REPO]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:関連コマンド: `リポジトリ`_
+
+
+plugins
+=======
+:目的: インストールされたプラグインの一覧を表示する。
+:使い方: bzr plugins
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ このコマンドはプラグインのバージョンとそれぞれの手短な説明を含めて
+ インストールされたプラグインの一覧を表示します
+
+ --verboseはそれぞれのプラグインが設置されたパスを表示します。
+
+ プラグインはコードを追加したり置き換えたりすることで
+ リビジョン管理システムを拡張する外部コンポーネントです。
+ コマンドの上書き、新しいコマンドの追加、追加のネットワーク転送の提供や
+ ログ出力のカスタマイズなどを含めて
+ プラグインはさまざまなことを行うことができます。
+
+ プラグインを見つけてインストール方法を含めた詳細な情報に関しては、
+ Bazaarのウェブサイト、http://bazaar-vcs.org を参照してください。
+ プログラミング言語のPyhonを利用して
+ 新しいコマンドを作成する方法に関する手引きもあります。
+
+
+
+pull
+====
+:目的: このブランチを別のブランチのミラーにする。
+:使い方: bzr pull [LOCATION]
+
+:オプション:
+ -v, --verbose pullされたリビジョン用のログを表示する。
+ --remember デフォルトとして指定されたロケーションを記録する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -d ARG, --directory=ARG
+ 作業ディレクトリを含むものよりもpullするブランチ。
+ --overwrite ブランチの間の違いを無視して無条件で上書きする。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:説明:
+ このコマンドは分岐されていないブランチのみで動作します。
+ 目的のブランチの最新の変更コミットが親にマージされなかった場合(直接もしくは間接)、
+ ブランチは分岐したものとして見なされます。
+
+ ブランチが分岐していれば、あるブランチからの変更を他のブランチに統合するために
+ 'bzr merge'を使用できます。
+ 一旦あるブランチがマージされると、他のブランチは再びそれをpullできるようになります。
+
+ ローカルの変更を忘れてリモートブランチを満たすようにブランチを更新したいだけなら、
+ pull --overwriteを使用します。
+
+ デフォルトのロケーションが存在しない場合、最初のpullはこれを設定します。
+ その後で、デフォルトを使用するロケーションを省略できます。
+ デフォルトを変更するには、--rememberを使用します。
+ リモートロケーションがアクセスできる場合のみ値は保存されます。
+
+ 注: 位置がブランチのフォーマットもしくはbzr sendで生成されたmergeディレクトリを格納する
+ ファイルへのパスで指定できます。
+
+:関連項目: `push`_, `status-flags`_, `update`_
+
+
+push
+====
+:目的: このブランチのミラーを更新する。
+:使い方: bzr push [LOCATION]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ --remember 指定された位置をデフォルトとして覚える。
+ --create-prefix まだ存在しなればブランチへのパスを作成する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --stacked-on=ARG コミットの履歴に関して別のブランチを参照するスタックドブランチを作成する。
+ 参照されるブランチに存在しない作業内容は作成されたブランチに格納される。
+ --use-existing-dir デフォルトでは、ターゲットのディレクトリが存在するが
+ まだコントロールディレクトリを持たない場合pushは失敗する。
+ このフラグはpushの続行を可能にする。
+ -d ARG, --directory=ARG
+ 作業ディレクトリを含むブランチよりも、pushするブランチ
+ --stacked 親ブランチの公開位置を参照するスタックドブランチを作成する。
+ --overwrite ブランチ間の違いを無視して無条件に上書きする。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:説明:
+ これは割高でリモートファイルシステムではサポートされないので、
+ ターゲットブランチは投入された作業ツリーを持ちません。
+
+ スマートサーバーもしくはプロトコルの中には将来作業ツリーを導入しないものがあります。
+
+ このコマンドは分岐されていないブランチでのみ動作します。
+ 目的のブランチの最新のコミットがソースブランチによって(直接もしくは間接的に)マージされなければ
+ ブランチは分岐されたものとして見なされます。
+
+ ブランチが分岐されると、他のブランチを完全に置き換えるために
+ 'bzr push --overwrite'を使用できます。この場合、マージされていない変更は廃棄されます。
+
+ 他のブランチに異なる変更があることを保証したい場合は、
+ 他のブランチからマージを行い(bzr help mergeを参照)、それをコミットします。
+ その後で'--overwrite'なしでpushを行うことができるようになります。
+
+ デフォルトのpush位置の設定がなければ、最初のpushはこれを設定します。
+ その後では、デフォルトを省略できます。
+ デフォルトを変更するには、--rememberを使用します。
+ リモート位置がアクセスできる場合のみ値は保存されます。
+
+:関連項目: `pull`_, `update`_, `working-trees`_
+
+
+reconcile
+=========
+:目的: ブランチのメタデータを調整する。
+:使い方: bzr reconcile [BRANCH]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ これは以前の実在しないオペレーションもしくはbzrの更新によって
+ 引き起こされるデータのミスマッチを訂正できます。
+ 'bzr check'もしくはbzrの開発者がそのコマンドを実行するようにアドバイスするのであれば、
+ このコマンドを実行することだけが必要になります。
+
+ 2番目のブランチが提供されると、
+ ブランチをまたがる調整も行われます。これによってbzrの初期のバージョンでは存在しなかった
+ ツリーのroot idのようなデータがチェックされ、両方のブランチで正しく表示されます。
+
+ 同時にデータが再圧縮されるのでディスクスペースの節約やパフォーマンスのゲインにつながります。
+
+ ブランチはローカルディスクもしくはsftpのようにリスト可能なシステム上になければなりません。
+
+:関連項目: `check`_
+
+
+reconfigure
+===========
+:目的: bzrディレクトリのタイプを再設定する。
+:使い方: bzr reconfigure [LOCATION]
+
+:オプション:
+ --force ローカルの変更が失われていた場合でも再設定を実行する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --bind-to=ARG チェックアウトをバインドするブランチ。
+ -h, --help ヘルプメッセージを表示する。
+
+ Target type:
+ --branch 作業ツリーを持たないバインドされていないブランチに再設定する。
+ --checkout 作業ツリーを持つバインドされたブランチに再設定する。
+ --lightweight-checkout
+ 軽量チェックアウトに再設定する(ローカルの履歴はなし)。
+ --standalone スタンドアロンブランチに再設定する(すなわち共用リポジトリの使用を停止する)。
+ --tree 作業ツリーを持つバインドされていないブランチに再設定する。
+ --use-shared 共用リポジトリを使用するように再設定する。
+
+:説明:
+ ターゲットの設定を指定しなければなりません。
+
+ チェックアウトに関しては指定されていなければ、bind-toのロケーションは自動検出されます。
+ 優先順位は
+ 1. 軽量チェックアウトに関しては、現在バインドされているロケーション。
+ 2. チェックアウトに使用されるブランチに関しては、以前バインドされたロケーション。
+ 3. pushのロケーション。
+ 4. 親のロケーション。
+ これらが利用できなければ、--bind-toを指定しなければなりません。
+
+:関連項目: `ブランチ`_, `チェックアウト`_, `スタンドアロンのツリー`_, `作業ツリー`_
+
+
+remerge
+=======
+:目的: マージを再び行う。
+:使い方: bzr remerge [FILE...]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ --reprocess 誤った衝突を減らすために再処理する。
+ -q, --quiet エラーと警告のみ表示する。
+ --show-base 衝突内のベースリビジョンのテキストを表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+ マージアルゴリズム:
+ --merge-type=ARG 特定のマージアルゴリズムを指定する。
+ --diff3 外部diff3を使用するマージ
+ --lca 新しいLCAマージ
+ --merge3 ネイティブのdiff3スタイルのマージ
+ --weave weaveベースのマージ
+
+:説明:
+ 衝突を解消している間に異なるマージテクニックを試したい場合はこれを使用します。
+ マージテクニックの中には他のものよりもすぐれたものがあり、
+ remergeによって異なるファイルで異なるテクニックを試すことができます。
+ remergeのオプションはmergeのものと同じ意味とデフォルトを持ちます。
+ 違いは未解決のマージが存在するときのみremergeは実行できて
+ 特定のファイルを指定できることです。
+
+:例:
+ すべてのファイルのマージを再実行し、通常のTHISとOTHERテキストに加えて、
+ 衝突領域のベーステキストを表示する::
+
+ bzr remerge --show-base
+
+ weaveマージアルゴリズムを使用して"foobar"のマージを再実行して、
+ 衝突領域のサイズを減らすために追加処理を行う::
+
+ bzr remerge --merge-type weave --reprocess foobar
+
+
+
+remove
+======
+:目的: ファイルもしくはディレクトリを除外する。
+:使い方: bzr remove [FILE...]
+
+:オプション:
+ --new けっしてコミットされなかったファイルのみを除外する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+ 削除戦略:
+ --force 指定されたファイルがリカバーできないまたは空のディレクトリではなくても
+ これらすべてを削除する。
+ --keep ファイルを削除しない。
+ --safe ファイルを安全にリカバーできるのであればファイルを削除することだけ行う(デフォルト)。
+
+:説明:
+ このコマンドによってbzrは指定されたファイルへの変更の追跡を止めます。
+ rebertコマンドで容易に復元できるのであればbzrはこれらのファイルを削除します。
+ オプションもしくはパラメータが与えられなければbzrは追跡されているファイルをスキャンしますが
+ ツリーの中で見つからなければそれらの追跡を停止します。
+
+:エイリアス: rm, del
+
+
+remove-tree
+===========
+:目的: 与えられたブランチ/チェックアウトから作業ツリーを除外する。
+:使い方: bzr remove-tree [LOCATION]
+
+:オプション:
+ --force コミットされていない変更があっても作業ツリーを除外する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 軽量チェックアウトは作業ツリーと大差ないので、これはそれに対する実行を拒絶します。
+
+ 作業ツリーを再現するには、"bzr checkout"を使用します。
+
+:関連項目: `checkout`_, `working-trees`_
+
+
+renames
+=======
+:目的: リネームされたファイルの一覧を表示する。
+:使い方: bzr renames [DIR]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:関連項目: `status`_
+
+
+resolve
+=======
+:目的: 衝突を解消されたものとしてマークする。
+:使い方: bzr resolve [FILE...]
+
+:オプション:
+ --all このツリーのすべての衝突を解消する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 2つのブランチの間の変更を結合するためにマージは最善を尽くしますが、
+ 人間だけが修正できる種類の問題があります。
+ この問題に遭遇するとき、衝突がマークされます。
+ 衝突はコミットする前に何かを修正する必要があることを意味します。
+
+ 一旦問題を修正すれば、自動的にテキストの衝突を修正したものとしてマークするために"bzr resolve"を使用し、
+ 特定の衝突を解消したものとしてマークするためにFILEをresolveします。
+ すべての衝突が解消されたものとしてマークするにはor "bzr resolve --all"を行います。
+
+:関連コマンド: `bzr conflicts`
+
+:エイリアス: resolved
+
+
+revert
+======
+:目的: ファイルを以前のリビジョンに差し戻す。
+:使い方: bzr revert [FILE...]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --forget-merges ファイルを変更せずに、未解決のマージマーカーを取り除く。
+ --no-backup 差し戻しされたファイルのバックアップを保存しない。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:説明:
+ 指定されたテキストだけを差し戻すファイルのリストを渡します。
+ さもなければ、すべてのファイルが差し戻されます。
+ '--revision'でリビジョンが指定されなければ、最後にコミットされたリビジョンが使用されます。
+
+ 以前のリビジョンに差し戻さずに、いくつかの変更を除外するには、代わりにmergeを使用します。
+ たとえば、"merge . --revision -2..-3"は-2で導入された変更を除外しますが、
+ -1で導入された変更には影響を与えません。
+ hunk-by-hunkベースである変更を除外するには、Shelfプラグインを参照してください。
+
+ デフォルトでは、手動で変更されてきたファイルは最初にバックアップされます。
+ (マージのみで変更されたファイルはバックアップされません。)
+ バックアップファイルの名前には '.~#~' が追加されます。#は番号です。
+
+ ファイルを提供する場合、現在のパス名もしくはターゲットリビジョンからのパス名を使用できます。
+ 名前でファイルを"undelete"するためにrevertを使用できます。
+ ディレクトリに名前をつけると、そのディレクトリのすべての内容が差し戻されます。
+
+ そのリビジョン以降に新しく追加されたファイルは削除されます。適切であればバックアップは維持されます。
+ 未知のファイルを持つディレクトリは削除されません。
+
+ 作業ツリーは未解決のマージされたリビジョンのリストを含みます。
+ これは次のコミットで親として含まれます。
+ 通常は、ファイルを差し戻すのと同様にrevertはそのリストをクリーンにします。
+ ファイルが指定されていれば、revertは未解決のマージリストをそのままにしてファイルだけを差し戻します。
+ すべてのファイルを差し戻すがマージの記録を維持するにはツリーのrootで"bzr revert ."を使用し、
+ ファイルの差し戻しを行わずに未解決のマージリストをクリアするには"bzr revert --forget-merges"を使用します。
+
+:関連項目: `cat`_, `export`_
+
+
+revno
+=====
+:目的: 現在のリビジョン番号を表示する。
+:使い方: bzr revno [LOCATION]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ これはこのブランチのリビジョン番号と等しいです。
+
+:関連項目: `info`_
+
+
+root
+====
+:目的: ツリーのrootディレクトリを表示する。
+:使い方: bzr root [FILENAME]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ The rootは.bzrコントロールディレクトリを持つもっとも近い同封ディレクトリです。
+
+send
+====
+:目的: 変更を投稿するためにメールを送るもしくはmergeディレクティブを作成する。
+:使い方: bzr send [SUBMIT_BRANCH] [PUBLIC_BRANCH]
+
+:オプション:
+ -f ARG, --from=ARG 作業ディレクトリを含むブランチよりも、投稿フォームを生成するブランチ。
+ --remember 投稿と公開ブランチを覚える。
+ --mail-to=ARG このアドレスにリクエストメールを送信する。
+ --format=ARG 指定されたフォーマットを使用する。
+ "0.9": バンドルフォーマット 0.9、マージディレクティブ 1。
+ "4": バンドルフォーマット 4、マージディレクティブ 2 (デフォルト)。
+ --no-bundle バンドルをmergeディレクティブに含めない。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -o ARG, --output=ARG mergeディレクティブをこのファイルに書き込む; stdout用に-を使用する。
+ -m ARG, --message=ARG
+ メッセージの文字列。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+ --no-patch mergeディレクティブにプレビューパッチを含めない。
+ -v, --verbose 詳細な情報を表示する。
+
+:説明:
+ mergeディレクティブはmergeリクエストを行うために必要な多くのものを提供します:
+
+ * 実行するマージのマシンが理解できる説明
+
+ * リクエストされた変更のプレビューであるオプションのパッチ
+
+ * リビジョンデータのオプションバンドル、
+ ブランチからデータを読み込まずに、mergeディレクトリからの変更を直接適用できるようになります。
+
+ --no-bundleが指定されると、public_branchが必要です(また最新でなければなりません)、
+ 受け取り手がpublic_branchを使用するマージを実行できるように
+ 後で他の人がチェックできるように、知っているのであればpublic_branchを常に含まれていなければなりません。
+
+ 投稿ブランチのデフォルトは親ですが、上書きできます。
+ 提供されれば投稿ブランチと公開ブランチの両方が記録されます。
+
+ public_branchがsubmit_branchに知られていれば、
+ その公開と投稿ブランチはマージのインストラクションで使用されます。
+ これはそのローカルミラーに対してpublic_branchを設定すれば、
+ そのミラーは実際の投稿ブランチとして使用できることを意味します。
+
+ メールは好きなプログラムで送信されます。
+ Windowsではこれは透過的です(MAPIが使用される)。
+ Linuxでは、xdg-emailユーティリティを必要とします。
+ 望ましいクライアントが見つからなければ(もしくは使用できなければ)、エディタが使用されます。
+
+ 特定のメールプログラムを使用するには、mail_client設定オプションを設定します。
+ (Thunderbird 1.5に関して、これはいくつかのバグに対処します。)
+ 特定のクライアント用にサポートされる値は"claws"、"evolution"、"kmail"、"mutt"、と"thunderbird";
+ 一般的なオプションは"default"、"editor"、"emacsclient"、"mapi"、と"xdg-email"です。
+ プラグインがサポートされるクライアントを追加することもあります。
+
+ メールが送信されている場合、to addressが必要になります。
+ これはコマンドライン、submit_to設定オプションをブランチ自身に設定するか、
+ 投稿ブランチでchild_submit_to設定オプションを設定することで提供できます。
+
+ 現在2つのフォーマットがサポートされています: "4"はリビジョンバンドルフォーマット4
+ とマージディレクトリフォーマット2です。
+ これは古いフォーマットよりも顕著に速く小さいです。
+ これはBazaar 0.19とそれ以降で互換性があります。
+ これはデフォルトです。
+ "0.9"はリビジョンバンドルフォーマット0.9とマージディレクティブフォーマット1を使用します。
+ これは0.12 - 0.18と互換性があります。
+
+ mergeもしくはpullコマンドを使用することでmergeディレクトリが適用されます。
+
+:関連項目: `merge`_, `pull`_
+
+
+serve
+=====
+:目的: bzrサーバーを稼働させる。
+:使い方: bzr serve
+
+:オプション:
+ --allow-writes デフォルトではサーバーはリードオンリーのサーバーです。
+ --allow-writesを提供すると提供されるディレクトリと
+ その下の内容への書き込み権限を有効にできる。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --directory=ARG このディレクトリの内容をサーブする。
+ --port=ARG [hostname:]portnumber形式で指名されたポート上で接続するためにリスンする。
+ 0をポート番号として割り当てるとポートは動的な割り当てになります。
+ デフォルトのポートは4155です。
+ --inet inetdもしくはsshdからの使用のためにstdin/outでserveする。
+ -h, --help ヘルプメッセージを表示する。
+
+:エイリアス: server
+
+
+shelve
+======
+:目的: いくつかの変更を現在のツリーから一時的に退避する。
+:使い方: bzr shelve [FILE...]
+
+:オプション:
+ --all すべての変更を退避する。
+ -v, --verbose 詳細な情報を表示する。
+ --list 退避された変更の一覧を表示する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -m ARG, --message=ARG
+ メッセージの文字列。
+ -r ARG, --revision=ARG
+ 詳細に関しては"help revisionspec"を参照。
+
+ writer:
+ --plain プレーンテキスト形式での差分の出力。
+
+:説明:
+ shelveによって変更を一時的に"棚に上げる"、すなわち邪魔にならない場所に置くことができます。
+ 'unshelve'コマンドで後で元に戻すことができます。
+
+ shelve --listが指定されると、以前退避された変更の一覧が表示されます。
+
+ shelveは不適切に混ぜられた変更のいくつかのセットの分離を手助けすることを目的としています。
+ すべての変更を除去したいだけで後で退避する必要がなければ、revertを使用します。
+ 一度にすべてのテキストの変更をshelveするには、shelve --allを使用します。
+
+ ファイル名が指定されると、それらのファイルの変更のみ退避されます。
+ 他のファイルは手つかずのままです。
+
+ リビジョンが指定されれば、そのリビジョン以降の変更は退避されます。
+
+ 複数のアイテムを退避することができ、デフォルトでは、
+ 'unshelve'は最近shelveされた変更を復元します。
+
+:関連項目: `unshelve`_
+
+sign-my-commits
+===============
+:目的: 与えられたコミッターですべてのコミットに署名する。
+:使い方: bzr sign-my-commits [LOCATION] [COMMITTER]
+
+:オプション:
+ --dry-run 実際に署名しない。
+ 署名されるリビジョンを表示するだけ。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 位置が指定されなければローカルツリーが使用されます。
+ コミッターが指定されなければデフォルトのコミッターが使用されます。
+
+ これはすでにシグネチャを持つコミットには署名しません。
+
+
+
+split
+=====
+:目的: ツリーのサブディレクトリを個別のツリーに分割する。
+:使い方: bzr split TREE
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ このコマンドは'rich-root' もしくは 'rich-root-pack'のように
+ リッチrootをサポートするフォーマットでターゲットツリーを生み出します。
+ これらのフォーマットは'dirstate-tags'のような初期のフォーマットに変換できません。
+
+ TREEの引数は作業ツリーのサブディレクトリになります。
+ そのサブディレクトリは独自のブランチを持つ独立したツリーに変換されます。
+ トップレベルツリーのコミットは新しいサブツリーに適用されません。
+
+
+
+status
+======
+:目的: ステータスの要約を表示する。
+:使い方: bzr status [FILE...]
+
+:オプション:
+ -S, --short 短いステータスインジケーターを表示する。
+ -v, --verbose 詳細な情報を表示する。
+ -V, --versioned バージョン管理されたファイルだけを表示する。
+ --no-pending 未解決のマージを表示しない。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --show-ids 内部オブジェクトidを表示する。
+ -c ARG, --change=ARG 指定されたリビジョンで導入された変更を選択する。
+ "help revisionspec"を参照。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:説明:
+ これはバージョン管理されたファイルと未知のファイルを状態で
+ 分類してレポートします。利用可能な状態は次のとおりです:
+
+ added
+ 作業ツリーでバージョン管理されているが以前のリビジョンではない。
+
+ removed
+ 以前のリビジョンでバージョン管理されているが作業コピーでは移動もしくは削除されている。
+
+ renamed
+ 以前のリビジョンから変更されたファイルのパス;
+ テキストも変更されていることがある。
+ これは親ディレクトリがリネームされたファイルを含む。
+
+ modified
+ 以前のリビジョン以降変更されたテキスト。
+
+ kind changed
+ 変更されたファイルの種類(たとえばファイルからディレクトリへ)。
+
+ unknown
+ バージョン管理されていないかつ無視パターンにマッチしない。
+
+ 無視されるファイルを見るには'bzr ignored'を使用します。
+ ファイルテキストへの詳細な変更に関しては、'bzr diff'を使用します。
+
+ --shortもしくは-Sは、Subversionのstatusコマンドに似た、
+ それぞれのアイテムに対するステータスフラグを提供することに注意してください。
+ svn -qと似たような出力を得るには、bzr status -SVを使用します。
+
+ 引数が指定されなければ、作業ディレクトリ全体のステータスが示されます。
+ さもなければ、指定されたファイルもしくはディレクトリのステータスのみが報告されます。
+ ディレクトリが渡されれば、そのディレクトリ内部のすべてに関するステータスが報告されます。
+
+ 1つのリビジョンの引数が渡されれば、ステータスはそのリビジョンに対して
+ 2つの引数の場合は2つのリビジョンの間で算出されます。
+
+:エイリアス: st, stat
+:関連項目: `diff`_, `revert`_, `status-flags`_
+
+
+switch
+======
+:目的: チェックアウトのブランチを設定してupdateする。
+:使い方: bzr switch TO_LOCATION
+
+:オプション:
+ --force ローカルコミットが失われていても切り替える。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ 軽量チェックアウトに対して、これは参照されているブランチを変更します。
+ 重量チェックアウトに対して、これはローカルコミットがなく、
+ バインドされたブランチがないことを確認して、
+ ローカルブランチを新しいロケーションのミラーにしてそれにバインドします。
+
+ 両方の場合において、作業ツリーはupdateされコミットされてない変更はマージされます。
+ ユーザーは望むのであればcommitもしくはrevertできます。
+
+ マージの追加にはswithを使用する前にcommitもしくはrevertする必要があります。
+
+ swithするブランチへのパスは現在のブランチの親ディレクトリに対して相対的に指定できます。
+ たとえば、現在/path/to/branchのチェックアウトの中にいるのであれば
+ 'newbranch'を指定すれば/path/to/newbranchでのブランチが発見されます。
+
+ ローカルに設定されていない限りバインドされたブランチはマスターブランチのニックネームを使用します。
+ この場合、switchを行うとローカルのニックネームはマスターのものに更新されます。
+
+
+tag
+===
+:目的: リビジョンを名づけっるタグを作成、削除もしくは修正する。
+:使い方: bzr tag TAG_NAME
+
+:オプション:
+ --force 既存のタグを置き換える。
+ -v, --verbose 詳細な情報を表示する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -d ARG, --directory=ARG
+ タグを設置するブランチ
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+ --delete 置き換えるよりもタグを削除する。
+
+:説明:
+ タグはリビジョンに人間が理解できる名前を与えます。
+ -r (--revision)オプションをとるコマンドは-rtag:Xに渡されます。
+ Xは以前作成されたタグです。
+
+ タグはブランチに保存されます。
+ branch、push、pullもしくはmergeを行うときタグはあるブランチから他のブランチにコピーされます。
+
+ --forceを渡さない限り、既存のタグ名を与えるとエラーになります。
+ この場合新しいリビジョンを示すようにタグは移動します。
+
+ タグをリネームする(名前を変更するが同じリビジョンで維持する)には、
+ ``bzr tag new-name -r tag:old-name`` と ``bzr tag --delete oldname`` を実行します。
+
+:関連項目: `commit`_, `tags`_
+
+
+tags
+====
+:目的: タグの一覧を表示する。
+:使い方: bzr tags
+
+:オプション:
+ --sort=ARG 異なる基準でタグをソートする。
+ "alpha": 辞書式でタグをソートする(デフォルト)。
+ "time": 年代順でタグをソートする。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -d ARG, --directory=ARG
+ タグが表示されるブランチ。
+ --show-ids 内部オブジェクトidを表示する。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ このコマンドはこれらが参照するタグ名とリビジョンのテーブルを表示します。
+
+:関連項目: `tag`_
+
+
+testament
+=========
+:目的: リビジョンのtestament(署名のフォーム)を表示する。
+:使い方: bzr testament [BRANCH]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --long 長いフォーマットのtestamentを生成する。
+ --strict 厳密なフォーマットのtestamentを生成する。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+
+
+unbind
+======
+:目的: 現在のチェックアウトを通常のブランチに変換する。
+:使い方: bzr unbind
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ unbindした後で、ローカルブランチは独立したものとして見なされ
+ その後のコミットはローカルのみで行われます。
+
+:関連項目: `bind`_, `チェックアウト`_
+
+
+uncommit
+========
+:目的: 最後にコミットされたリビジョンを削除する。
+:使い方: bzr uncommit [LOCATION]
+
+:オプション:
+ --dry-run 実際には変更しない。
+ -v, --verbose 詳細な情報を表示する。
+ -h, --help ヘルプメッセージを表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --force すべての質問にyesと答える。
+ --local チェックアウトのときローカルブランチからコミットのみを削除する。
+ -r ARG, --revision=ARG
+ 詳細は"help revisionspec"を参照。
+
+:説明:
+ --verboseは削除されているものを表示します。
+ --dry-runはすべてのモーションを経験しますが、実際には何も削除しません。
+
+ --revisionが指定されると、指定されたリビジョンでブランチをそのままにするために
+ リビジョンをuncommitします。たとえば、"bzr uncommit -r 15"はリビジョン15でのブランチを
+ そのままにします。
+
+ uncommitは新しいコミットの準備ができている作業ツリーをそのままにします。
+ 唯一行われる変更はコミット以前に存在していた追加マージをリストアすることです。
+
+:関連項目: `commit`_
+
+unshelve
+========
+:目的: shelveされた変更を復元する。
+:使い方Usage: bzr unshelve [SHELF_ID]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+ アクション:
+ --apply 変更を適用してshelfから削除する。
+ --delete-only 変更を適用せずにそれらを削除する。
+ --dry-run 編子を表示するがそれらを適用もしくは除外しない。
+
+:説明:
+ デフォルトでは、最近shelveされた変更が復元されます。
+ んまでパッチを指定したとしてもそれらの変更が代わりに復元されます。
+ 変更がお互いに依存しないときにこれはもっとも良く機能します。
+
+:関連項目: `shelve`_
+
+
+update
+======
+:目的: ブランチにコミットした最新コードにツリーを更新する。
+:使い方: bzr update [DIR]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+:説明:
+ このコマンドは作業ツリーでマージを実行し、衝突を生成することがあります。
+ ローカルの変更がある場合、updateを完了させるために
+ updateの後でそれらをコミットする必要があります。
+
+ ローカルの変更を破棄したい場合、updateの後で'bzr commit'の代わりに
+ 'bzr revert'を使用できます。
+
+:エイリアス: up
+:関連項目: `pull`_, `status-flags`_, `working-trees`_
+
+
+upgrade
+=======
+:目的: ブランチのストレージを現在のフォーマットにアップグレードする。
+:使い方: bzr upgrade [URL]
+
+:オプション:
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+ ブランチのフォーマット::
+
+ --format=ARG このブランチのフォーマットを指定する。"help formats"を参照。
+ --1.12-preview ビューとコンテンツのフィルタリングをサポートする作業ツリーフォーマット。
+ --1.12-preview-rich-root
+ rich-rootデータをサポートする1.12-previewのバリアント(bzr-svnに必要)
+ --1.6 スタックをサポートするリポジトリに基づいたブランチとパック。
+ --1.6.1-rich-root スタックとリッチなrootデータをサポートするリポジトリに基づいた
+ ブランチとパック(bzr-svnに必要)。
+ --1.9 btreeインデックスを使用するリポジトリに基づいたブランチとパック
+ --1.9-rich-root btreeインデックスとリッチrootデータを使用する
+ リポジトリに基づいたブランチとパック(bzr-svnに必要)。
+ --default 0.92の新しい機能: dirstate-tagsフォーマットリポジトリと
+ 互換性のあるデータを持つパックベースのフォーマット。
+ 0.92以前のbzrリポジトリと相互運用しますが
+ bzr < 0.92では読むことができません。
+ 以前はknitpack-experimentalと呼ばれていました。
+ 詳細な情報は http://doc.bazaar-vcs.org/latest/developers/packrepo.html を参照。
+ --development 現在の開発フォーマット。データをpack-0.92 (とpack-0.92と互換性のある)
+ フォーマットリポジトリに変換できる。
+ このフォーマットのリポジトリとブランチはbzr.devによってのみ読み込みできます。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-repo.html を参照して頂くようお願いします。
+ --development-subtree
+ 現在の開発フォーマットで、subtreeバリアント。
+ データをpack-0.92-subtree(とpack-0.92-subtreeと互換性のある)
+ フォーマットリポジトリに変換できる。
+ このフォーマットのリポジトリとブランチはbzr.devでのみ読み込みできる。
+ 使用する前に http://doc.bazaar-vcs.org/latest/developers/development-
+ repo.html をご覧いただくようお願いします。
+ --dirstate 0.15の新しいフォーマット: 速いローカルオペレーション。
+ ネットワークを通したアクセスのときbzr 0.8とそれ以降と互換性がある。
+ --dirstate-tags 0.15の新しいフォーマット: 速いローカルオペレーションで
+ ネットワークオペレーションに関するスケーリングを改善。
+ タグのサポートを追加。bzr < 0.15とは互換性がない。
+ --knit knitsを使用するフォーマット。bzr <= 0.14との相互運用に推奨。
+ --metaweave 0.8での暫定フォーマット。knitよりも遅い。
+ --pack-0.92 0.92の新しいフォーマット: dirstate-tagsフォーマットリポジトリと
+ 互換性のあるデータを持つパックベースのフォーマット。
+ 0.92以前のbzrリポジトリと相互運用できるがbzr < 0.92.によって読み込みできない。
+ 以前はknitpack-experimentalと呼ばれていた。
+ 詳細な情報に関しては、 http://doc
+ .bazaar-vcs.org/latest/developers/packrepo.html を参照。
+ --rich-root 1.0の新しいフォーマット。ツリーrootのベターな扱い。
+ bzr < 1.0と互換性がない。
+ --rich-root-pack 1.0の新しいフォーマット: rich-rootデータをサポートする
+ pack-0.92のバリアント(bzr-svnに必要)。
+ --weave 0.8以前のフォーマット。knitよりも遅く
+ チェックアウトもしくは共用リポジトリをサポートしない。
+
+:説明:
+ ときどきこのコマンドを実行するにcheckコマンドもしくはbzrの開発者がアドバイスすることがあります。
+ デフォルトフォーマットが変更されたときアップグレードする他のオペレーションの実行中に警告されることもあります。
+
+:関連コマンド: `check`_
+
+
+version
+=======
+:目的: bzrのバージョンを表示する
+:使い方: bzr version
+
+:オプション:
+ --short バージョン番号だけを表示する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告だけ表示する。
+ -h, --help ヘルプメッセージを表示する。
+
+
+
+version-info
+============
+:目的: このツリーに関するバージョン情報を表示する。
+:使い方: bzr version-info [LOCATION]
+
+:オプション:
+ --all すべての入手可能な情報を含める。
+ -v, --verbose 詳細な情報を表示する。
+ --check-clean ツリーがクリーンであるかチェックする。
+ --include-history リビジョンの履歴を含める。
+ -q, --quiet エラーと警告のみを表示する。
+ --template=ARG 出力用のテンプレート。
+ --include-file-revisions
+ それぞれのファイルに対する最終リビジョンを含める。
+ -h, --help ヘルプメッセージを表示する。
+
+ フォーマット::
+ --format=ARG 出力フォーマットを選択する。
+ --custom カスタムテンプレートベースのフォーマットでのバージョン情報。
+ --python Pythonフォーマットでのバージョン情報。
+ --rio RIOフォーマット(シンプルなテキスト)でのバージョン情報(デフォルト)。
+
+:説明:
+ バージョンに関する情報をアプリケーションのソースコードに追加するために
+ このコマンドを使用できます。出力のフォーマットはサポートされているもの1つか
+ テンプレートに基づいてカスタマイズされたものです。
+
+ 例::
+
+ bzr version-info --custom \
+ --template="#define VERSION_INFO \"Project 1.2.3 (r{revno})\"\n"
+
+ 現在のリビジョン番号を含むフォーマットされた文字列でCヘッダファイルを生成します。
+ テンプレートでのサポートされた他の変数は次のとおりです:
+
+ * {date} - 最終リビジョンの日付
+ * {build_date} - 現在の日付
+ * {revno} - リビジョン番号
+ * {revision_id} - リビジョンid
+ * {branch_nick} - ブランチのニックネーム
+ * {clean} - ソースコードがコミットされていない変更を含むときは0でそれ以外は1
+
+
+
+whoami
+======
+:目的: bzrのユーザーidを表示もしくは設定する。
+:使い方: bzr whoami [NAME]
+
+:オプション:
+ --email Eメールアドレスのみ表示する。
+ -v, --verbose 詳細な情報を表示する。
+ -q, --quiet エラーと警告のみを表示する。
+ --branch グローバルの代わりに現在のブランチ用のIDを設定する。
+ -h, --help ヘルプメッセージを表示する。
+
+:例:
+ 現在のユーザーのEメールを表示する::
+
+ bzr whoami --email
+
+ 現在のユーザーを設定する::
+
+ bzr whoami "Frank Chu <fchu@example.com>"
+
+
+
+
diff --git a/doc/news-template.txt b/doc/news-template.txt
new file mode 100644
index 0000000..0ede1ee
--- /dev/null
+++ b/doc/news-template.txt
@@ -0,0 +1,20 @@
+
+
+NOT RELEASED YET
+----------------
+
+ COMPATABILITY BREAKS:
+
+ NEW FEATURES:
+
+ IMPROVEMENTS:
+
+ BUG FIXES:
+
+ DOCUMENTATION:
+
+ API CHANGES:
+
+ TESTING:
+
+ INTERNALS:
diff --git a/doc/ru/_static/bzr icon 16.png b/doc/ru/_static/bzr icon 16.png
new file mode 100644
index 0000000..0c8d454
--- /dev/null
+++ b/doc/ru/_static/bzr icon 16.png
Binary files differ
diff --git a/doc/ru/_static/bzr.ico b/doc/ru/_static/bzr.ico
new file mode 100644
index 0000000..a49eb7e
--- /dev/null
+++ b/doc/ru/_static/bzr.ico
Binary files differ
diff --git a/doc/ru/_static/ru/Makefile b/doc/ru/_static/ru/Makefile
new file mode 100644
index 0000000..935a574
--- /dev/null
+++ b/doc/ru/_static/ru/Makefile
@@ -0,0 +1,19 @@
+TARGETS=bzr-quick-reference.png bzr-quick-reference.pdf
+OBJECTS=bzr-quick-reference.svg Makefile
+
+all: $(TARGETS)
+
+.SUFFIXES: .svg .png .pdf
+
+.svg.pdf:
+ rsvg-convert -d 300 -p 300 -f pdf -o $@ $<
+
+.svg.png:
+ rsvg-convert -d 300 -p 300 -z 3.3346 -f png -o $@ $<
+
+bzr-quick-reference.png: $(OBJECTS)
+
+bzr-quick-reference.pdf: $(OBJECTS)
+
+clean:
+ rm -f $(TARGETS)
diff --git a/doc/ru/_static/ru/bzr-ru-quick-reference.pdf b/doc/ru/_static/ru/bzr-ru-quick-reference.pdf
new file mode 100644
index 0000000..f8bea33
--- /dev/null
+++ b/doc/ru/_static/ru/bzr-ru-quick-reference.pdf
Binary files differ
diff --git a/doc/ru/_static/ru/bzr-ru-quick-reference.png b/doc/ru/_static/ru/bzr-ru-quick-reference.png
new file mode 100644
index 0000000..d570fa9
--- /dev/null
+++ b/doc/ru/_static/ru/bzr-ru-quick-reference.png
Binary files differ
diff --git a/doc/ru/_static/ru/bzr-ru-quick-reference.svg b/doc/ru/_static/ru/bzr-ru-quick-reference.svg
new file mode 100644
index 0000000..aed0dc0
--- /dev/null
+++ b/doc/ru/_static/ru/bzr-ru-quick-reference.svg
@@ -0,0 +1,1601 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2766"
+ sodipodi:version="0.32"
+ inkscape:version="0.46"
+ version="1.0"
+ sodipodi:docbase="/home/ian/bzr/repo.packs/bzr.quick-start-tweaks/doc/en/quick-reference"
+ sodipodi:docname="quick-start-summary.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ashtokalo/projects/bazaar/bzr/doc/ru/quick-reference/quick-start-summary.png"
+ inkscape:export-xdpi="300"
+ inkscape:export-ydpi="300">
+ <defs
+ id="defs2768">
+ <inkscape:perspective
+ sodipodi:type="inkscape:persp3d"
+ inkscape:vp_x="0 : 372.04724 : 1"
+ inkscape:vp_y="0 : 1000 : 0"
+ inkscape:vp_z="1052.3622 : 372.04724 : 1"
+ inkscape:persp3d-origin="526.18109 : 248.03149 : 1"
+ id="perspective299" />
+ <linearGradient
+ id="linearGradient3382">
+ <stop
+ style="stop-color:#2754b0;stop-opacity:1;"
+ offset="0"
+ id="stop3384" />
+ <stop
+ style="stop-color:#cecece;stop-opacity:1;"
+ offset="1"
+ id="stop3386" />
+ </linearGradient>
+ <linearGradient
+ gradientTransform="matrix(1.027169,0,0,1,118.6039,77.1455)"
+ gradientUnits="userSpaceOnUse"
+ y2="0"
+ x2="372.24512"
+ y1="69.037941"
+ x1="372.24512"
+ id="linearGradient2200"
+ xlink:href="#linearGradient5444"
+ inkscape:collect="always" />
+ <linearGradient
+ id="linearGradient5444">
+ <stop
+ style="stop-color:#729fcf;stop-opacity:1;"
+ offset="0"
+ id="stop5446" />
+ <stop
+ id="stop4547"
+ offset="0.5"
+ style="stop-color:#3465a4;stop-opacity:1;" />
+ <stop
+ style="stop-color:#204ab7;stop-opacity:1;"
+ offset="1"
+ id="stop5448" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient5444"
+ id="linearGradient3338"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.027169,0,0,1,417.31189,-41.4259)"
+ x1="372.24512"
+ y1="69.037941"
+ x2="372.24512"
+ y2="0" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient2733"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(0,26)"
+ x1="150.39197"
+ y1="104.09448"
+ x2="151.10625"
+ y2="155.92776" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3518"
+ x1="256.75"
+ y1="129.84448"
+ x2="256.75"
+ y2="194.09644"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3673"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(0,6.6792164e-6)"
+ spreadMethod="pad"
+ x1="15.75"
+ y1="133.84448"
+ x2="15.75"
+ y2="187.6799" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3727"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(-3.238024e-5,1e-5)"
+ spreadMethod="pad"
+ x1="256.75"
+ y1="129.84448"
+ x2="256.75"
+ y2="183.6799" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3733"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(-2.797738e-8,6.6341624e-6)"
+ spreadMethod="pad"
+ x1="256.75"
+ y1="129.84448"
+ x2="256.75"
+ y2="183.6799" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3745"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(-3e-5,9.4726875e-6)"
+ spreadMethod="pad"
+ x1="256.75"
+ y1="129.84448"
+ x2="256.75"
+ y2="183.6799" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3841"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(-3e-5,-18.00002)"
+ spreadMethod="pad"
+ x1="262.82553"
+ y1="400.06738"
+ x2="262.82553"
+ y2="453.20166" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3946"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(0,8.4764986e-6)"
+ spreadMethod="pad"
+ x1="255.99055"
+ y1="375.90359"
+ x2="255.99055"
+ y2="429.73904" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3980"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(-3e-5,-18.00002)"
+ spreadMethod="pad"
+ x1="262.82553"
+ y1="400.06738"
+ x2="262.82553"
+ y2="453.20166" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3382"
+ id="linearGradient3984"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="translate(-3e-5,1.0501135e-5)"
+ spreadMethod="pad"
+ x1="262.82553"
+ y1="400.06738"
+ x2="262.82553"
+ y2="453.20166" />
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="1"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="536.00788"
+ inkscape:cy="344.00003"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09449px"
+ inkscape:showpageshadow="false"
+ showgrid="false"
+ inkscape:window-width="1280"
+ inkscape:window-height="969"
+ inkscape:window-x="0"
+ inkscape:window-y="24"
+ showguides="false"
+ inkscape:guide-bbox="true">
+ <sodipodi:guide
+ orientation="0,1"
+ position="736,32"
+ id="guide2724" />
+ <sodipodi:guide
+ orientation="1,0"
+ position="50,461"
+ id="guide3531" />
+ <sodipodi:guide
+ orientation="0,1"
+ position="285.55009,613.5"
+ id="guide3613" />
+ <sodipodi:guide
+ orientation="0,1"
+ position="514.90148,462.50001"
+ id="guide3659" />
+ <sodipodi:guide
+ orientation="0,1"
+ position="710.07801,344.0271"
+ id="guide3835" />
+ <sodipodi:guide
+ orientation="0,1"
+ position="283.27176,368.32923"
+ id="guide3940" />
+ <sodipodi:guide
+ orientation="1,0"
+ position="999,424"
+ id="guide3986" />
+ </sodipodi:namedview>
+ <metadata
+ id="metadata2771">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <cc:license
+ rdf:resource="http://creativecommons.org/licenses/GPL/2.0/" />
+ <dc:title>Bazaar-NG quick reference</dc:title>
+ <dc:date>2007-07-23</dc:date>
+ <dc:creator>
+ <cc:Agent>
+ <dc:title>Sabin Iacob</dc:title>
+ </cc:Agent>
+ </dc:creator>
+ <dc:language>en</dc:language>
+ <dc:subject>
+ <rdf:Bag>
+ <rdf:li>bzr</rdf:li>
+ <rdf:li>bazaar</rdf:li>
+ <rdf:li>reference</rdf:li>
+ </rdf:Bag>
+ </dc:subject>
+ </cc:Work>
+ <cc:License
+ rdf:about="http://creativecommons.org/licenses/GPL/2.0/">
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/Reproduction" />
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/Distribution" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/Notice" />
+ <cc:permits
+ rdf:resource="http://web.resource.org/cc/DerivativeWorks" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/ShareAlike" />
+ <cc:requires
+ rdf:resource="http://web.resource.org/cc/SourceCode" />
+ </cc:License>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <rect
+ style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3988"
+ width="1052"
+ height="744"
+ x="0"
+ y="0.094482422"
+ sodipodi:insensitive="true" />
+ <rect
+ style="fill:url(#linearGradient3984);fill-opacity:1;fill-rule:nonzero;stroke:#cecece;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3823"
+ width="229"
+ height="312"
+ x="770.50006"
+ y="400.59448"
+ ry="8.1168795"
+ rx="8.1168776" />
+ <rect
+ rx="8.1168776"
+ ry="8.1168776"
+ y="430.09451"
+ x="771"
+ height="282"
+ width="228"
+ id="rect3825"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <g
+ id="g3942">
+ <rect
+ style="fill:url(#linearGradient3946);fill-opacity:1;fill-rule:nonzero;stroke:#cecece;stroke-width:0.99999988;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3930"
+ width="229"
+ height="336"
+ x="50.5"
+ y="376.59448"
+ ry="8.1168776"
+ rx="8.1168776" />
+ <rect
+ rx="8.1168776"
+ ry="8.1168776"
+ y="406.09448"
+ x="51"
+ height="306"
+ width="228"
+ id="rect3932"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ </g>
+ <rect
+ style="opacity:1;fill:none;fill-opacity:0;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect2983"
+ width="1052.1749"
+ height="744"
+ x="0"
+ y="0.094482422"
+ ry="0" />
+ <g
+ id="g3675">
+ <rect
+ rx="8.1168776"
+ ry="8.1168776"
+ y="130.59448"
+ x="50.5"
+ height="230"
+ width="229"
+ id="rect3510"
+ style="fill:url(#linearGradient3673);fill-opacity:1;fill-rule:nonzero;stroke:#cecece;stroke-width:0.99999994000000003;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <rect
+ style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3520"
+ width="228"
+ height="198.99998"
+ x="51"
+ y="161.0945"
+ ry="8.1168776"
+ rx="8.1168776" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="97.015038"
+ y="150.97269"
+ id="text3164"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3166"
+ x="97.015038"
+ y="150.97269">Инициализация</tspan></text>
+ <g
+ id="g3209"
+ transform="translate(1e-4,-2.2095387)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text2167"
+ y="193.07361"
+ x="63.794312"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan2171"
+ y="193.07361"
+ x="63.794312"
+ sodipodi:role="line">bzr init myproject</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3168"
+ y="179.83536"
+ x="58.209351"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="179.83536"
+ x="58.209351"
+ id="tspan3170"
+ sodipodi:role="line">Новый проект</tspan></text>
+ </g>
+ <g
+ id="g3215"
+ transform="translate(1e-4,-1.1449276)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text2175"
+ y="226.45848"
+ x="64.448624"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="226.45848"
+ x="64.448624"
+ id="tspan2177"
+ sodipodi:role="line">cd myproject</tspan><tspan
+ id="tspan2179"
+ y="237.53181"
+ x="64.448624"
+ sodipodi:role="line">bzr init</tspan><tspan
+ id="tspan2181"
+ y="248.60515"
+ x="64.448624"
+ sodipodi:role="line">bzr add .</tspan><tspan
+ id="tspan2183"
+ y="259.67847"
+ x="64.448624"
+ sodipodi:role="line" /></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3172"
+ y="213.22023"
+ x="58.174194"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="213.22023"
+ x="58.174194"
+ id="tspan3174"
+ sodipodi:role="line">Существующий проект</tspan></text>
+ </g>
+ <g
+ id="g3224"
+ transform="translate(1e-4,5.3457864e-2)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text2185"
+ y="277.48495"
+ x="64.448624"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="277.48495"
+ x="64.448624"
+ id="tspan2187"
+ sodipodi:role="line">bzr branch mp myproject</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3176"
+ y="266.6666"
+ x="58.209351"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="266.6666"
+ x="58.209351"
+ id="tspan3178"
+ sodipodi:role="line">Новая ветка</tspan></text>
+ </g>
+ <g
+ id="g3230"
+ transform="translate(1e-4,1.1181147)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3404"
+ y="308.44989"
+ x="64.448624"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="308.44989"
+ x="64.448624"
+ id="tspan3406"
+ sodipodi:role="line">bzr checkout mp myproject</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3408"
+ y="297.63153"
+ x="58.209351"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="297.63153"
+ x="58.209351"
+ id="tspan3410"
+ sodipodi:role="line">Новая рабочая копия</tspan></text>
+ </g>
+ <g
+ id="g3236"
+ transform="translate(1e-4,2.1828937)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3414"
+ y="341.88864"
+ x="64.448624"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ y="341.88864"
+ x="64.448624"
+ sodipodi:role="line"
+ id="tspan3424">bzr checkout --lightweight mp \</tspan><tspan
+ id="tspan2780"
+ y="352.96198"
+ x="64.448624"
+ sodipodi:role="line"> myproject</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3418"
+ y="328.59634"
+ x="58.209351"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="328.59634"
+ x="58.209351"
+ sodipodi:role="line"
+ id="tspan3422">Новая копия без истории</tspan></text>
+ </g>
+ <rect
+ rx="8.1168776"
+ ry="8.1168785"
+ y="130.59448"
+ x="302.5"
+ height="151"
+ width="236.99998"
+ id="rect3623"
+ style="fill:url(#linearGradient3733);fill-opacity:1;fill-rule:nonzero;stroke:#cecece;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <rect
+ style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3625"
+ width="236"
+ height="120"
+ x="303"
+ y="161.09448"
+ ry="8.1168776"
+ rx="8.1168776" />
+ <text
+ xml:space="preserve"
+ style="font-size:16.82818985px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="295.88339"
+ y="158.7634"
+ id="text3563"
+ sodipodi:linespacing="100%"
+ transform="scale(1.0517619,0.9507855)"><tspan
+ sodipodi:role="line"
+ id="tspan3565"
+ x="295.88339"
+ y="158.7634">Операции с файлами</tspan></text>
+ <g
+ id="g3243"
+ transform="matrix(1.0549376,0,0,1,-32.744004,-1.9729054)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3610"
+ y="203.36041"
+ x="332.47345"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan3612"
+ y="203.36041"
+ x="332.47345"
+ sodipodi:role="line">bzr add foo.py</tspan><tspan
+ y="214.43375"
+ x="332.47345"
+ sodipodi:role="line"
+ id="tspan3618">bzr add bar/</tspan></text>
+ <text
+ sodipodi:linespacing="110%"
+ id="text3614"
+ y="179.59872"
+ x="326.88849"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="179.59872"
+ x="326.88849"
+ id="tspan3616"
+ sodipodi:role="line">Добавить файл для</tspan><tspan
+ id="tspan3047"
+ y="192.79872"
+ x="326.88849"
+ sodipodi:role="line">контроля</tspan></text>
+ </g>
+ <g
+ id="g3250"
+ transform="matrix(1.0549376,0,0,1,-32.744004,7.0676505)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3622"
+ y="233.11641"
+ x="331.78732"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan3624"
+ y="233.11641"
+ x="331.78732"
+ sodipodi:role="line">bzr remove --keep foo.py</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3626"
+ y="221.35472"
+ x="326.20236"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="221.35472"
+ x="326.20236"
+ id="tspan3628"
+ sodipodi:role="line">Отменить контроль файла</tspan></text>
+ </g>
+ <g
+ id="g3256"
+ transform="matrix(1.0549376,0,0,1,-32.744004,4.1322158)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text3632"
+ y="266.08142"
+ x="331.81714"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan3634"
+ y="266.08142"
+ x="331.81714"
+ sodipodi:role="line">bzr remove --force foo.py</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text3636"
+ y="253.26308"
+ x="326.23218"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ id="tspan3049"
+ y="253.26308"
+ x="326.23218"
+ sodipodi:role="line">Отменить контроль и удалить</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="103.15869"
+ y="396.96985"
+ id="text3786"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3788"
+ x="103.15869"
+ y="396.96985">Информация</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.69986"
+ y="437.78763"
+ id="text3234"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="62.69986"
+ y="437.78763"
+ id="tspan3236">bzr status</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="57.114899"
+ y="424.54938"
+ id="text3238"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3240"
+ x="57.114899"
+ y="424.54938">Состояние рабочего дерева</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.72134"
+ y="470.33978"
+ id="text3244"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="62.72134"
+ y="470.33978"
+ id="tspan3250">bzr log</tspan><tspan
+ id="tspan3294"
+ sodipodi:role="line"
+ x="62.72134"
+ y="481.41312">bzr log foo.py</tspan><tspan
+ sodipodi:role="line"
+ x="62.72134"
+ y="492.48645"
+ id="tspan3252" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.446926"
+ y="457.04749"
+ id="text3254"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3256"
+ x="56.446926"
+ y="457.04749">Журнал ревизий</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="63.35416"
+ y="515.93146"
+ id="text3260"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3262"
+ x="63.35416"
+ y="515.93146">bzr diff</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="57.114902"
+ y="502.69315"
+ id="text3264"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3266"
+ x="57.114902"
+ y="502.69315">Изменения в рабочем дереве</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.744778"
+ y="626.90851"
+ id="text3298"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3300"
+ x="62.744778"
+ y="626.90851">bzr missing</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.50552"
+ y="613.67029"
+ id="text3302"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3304"
+ x="56.50552"
+ y="613.67029">Отсутствующие ревизии</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.7565"
+ y="703.50507"
+ id="text3308"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3310"
+ x="62.7565"
+ y="703.50507">bzr cat -r3 foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.517242"
+ y="678.26678"
+ id="text3312"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ x="56.517242"
+ y="678.26678"
+ id="tspan3043">Содержимое foo.py в</tspan><tspan
+ sodipodi:role="line"
+ x="56.517242"
+ y="690.26678"
+ id="tspan3046">ревизии 3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.686188"
+ y="659.00696"
+ id="text3318"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3320"
+ x="62.686188"
+ y="659.00696">bzr info</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.44693"
+ y="648.1886"
+ id="text3322"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3324"
+ x="56.44693"
+ y="648.1886">Информация о ветке</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.879551"
+ y="548.42957"
+ id="text3330"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3332"
+ x="62.879551"
+ y="548.42957">bzr diff foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="56.640293"
+ y="535.19128"
+ id="text3334"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3336"
+ x="56.640293"
+ y="535.19128">Изменения в foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="62.000778"
+ y="592.45911"
+ id="text3699"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan3701"
+ x="62.000778"
+ y="592.45911">bzr diff -r1..3 foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="55.76152"
+ y="567.64081"
+ id="text3703"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ x="55.76152"
+ y="567.64081"
+ id="tspan2746">Изменения в foo.py между</tspan><tspan
+ sodipodi:role="line"
+ x="55.76152"
+ y="579.64081"
+ id="tspan3039">ревизиями 1 and 3</tspan></text>
+ <rect
+ style="fill:url(#linearGradient3727);fill-opacity:1;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3685"
+ width="188.99971"
+ height="151"
+ x="560.50012"
+ y="130.59448"
+ ry="8.1168785"
+ rx="8.1168776" />
+ <rect
+ rx="8.1168776"
+ ry="8.1168776"
+ y="161.09448"
+ x="561"
+ height="120"
+ width="188"
+ id="rect3687"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="577.6239"
+ y="150.94995"
+ id="text4134"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4136"
+ x="577.6239"
+ y="150.94995">Контроль версий</tspan></text>
+ <g
+ id="g3262"
+ transform="translate(16.728023,-2.4445851)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4140"
+ y="190.88873"
+ x="559.03162"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan4142"
+ y="190.88873"
+ x="559.03162"
+ sodipodi:role="line">bzr commit foo.py -m &quot;foo&quot;</tspan><tspan
+ y="201.96207"
+ x="559.03162"
+ sodipodi:role="line"
+ id="tspan4144">bzr commit -m &quot;the rest&quot;</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4146"
+ y="180.0704"
+ x="553.44666"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="180.0704"
+ x="553.44666"
+ id="tspan4148"
+ sodipodi:role="line">Фиксировать изменения</tspan></text>
+ </g>
+ <g
+ id="g3269"
+ transform="translate(16.728023,7.3032391)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4152"
+ y="234.2924"
+ x="558.37482"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan4154"
+ y="234.2924"
+ x="558.37482"
+ sodipodi:role="line">bzr uncommit</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4156"
+ y="209.47408"
+ x="552.78986"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="209.47408"
+ x="552.78986"
+ id="tspan4158"
+ sodipodi:role="line">Откатить последную</tspan><tspan
+ id="tspan3045"
+ y="221.47408"
+ x="552.78986"
+ sodipodi:role="line">фиксацию</tspan></text>
+ </g>
+ <g
+ id="g3275"
+ transform="translate(16.728023,6.3548354)">
+ <text
+ sodipodi:linespacing="110%"
+ id="text4162"
+ y="263.73889"
+ x="558.37488"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ xml:space="preserve"><tspan
+ id="tspan4164"
+ y="263.73889"
+ x="558.37488"
+ sodipodi:role="line">bzr revert</tspan></text>
+ <text
+ sodipodi:linespacing="100%"
+ id="text4166"
+ y="250.50064"
+ x="552.78992"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="250.50064"
+ x="552.78992"
+ id="tspan4168"
+ sodipodi:role="line">Отменить изменения</tspan></text>
+ </g>
+ <g
+ id="g3741">
+ <rect
+ style="fill:url(#linearGradient3745);fill-opacity:1;fill-rule:nonzero;stroke:#cecece;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+ id="rect3735"
+ width="229"
+ height="254"
+ x="770.50006"
+ y="130.59448"
+ ry="8.1168795"
+ rx="8.1168776" />
+ <rect
+ rx="8.1168776"
+ ry="8.1168776"
+ y="161.09448"
+ x="771"
+ height="223"
+ width="228"
+ id="rect3737"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.99999994;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:1;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="825.24872"
+ y="150.97269"
+ id="text4236"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4238"
+ x="825.24872"
+ y="150.97269">Объединение</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="783.75763"
+ y="190.86407"
+ id="text4242"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="783.75763"
+ y="190.86407"
+ id="tspan4244">cd myproject</tspan><tspan
+ sodipodi:role="line"
+ x="783.75763"
+ y="201.93741"
+ id="tspan4296">bzr merge ../myproject-foo</tspan><tspan
+ sodipodi:role="line"
+ x="783.75763"
+ y="213.01074"
+ id="tspan4298">bzr commit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17267"
+ y="177.62582"
+ id="text4246"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4248"
+ x="778.17267"
+ y="177.62582">Объединение двух веток</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.44708"
+ y="255.5088"
+ id="text4252"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4254"
+ x="784.44708"
+ y="255.5088">cd myproject-foo</tspan><tspan
+ sodipodi:role="line"
+ x="784.44708"
+ y="266.58215"
+ id="tspan4258">bzr pull ../myproject</tspan><tspan
+ sodipodi:role="line"
+ x="784.44708"
+ y="277.65549"
+ id="tspan4260" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17267"
+ y="232.27057"
+ id="text4262"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4264"
+ x="778.17267"
+ y="232.27057">Получить изменения из </tspan><tspan
+ sodipodi:role="line"
+ x="778.17267"
+ y="244.27057"
+ id="tspan2726">myproject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.41193"
+ y="300.93793"
+ id="text4268"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4270"
+ x="784.41193"
+ y="300.93793">bzr update</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.17267"
+ y="287.7934"
+ id="text4272"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4274"
+ x="778.17267"
+ y="287.7934">Обновить рабочую копию</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="785.4549"
+ y="345.02151"
+ id="text4278"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4280"
+ x="785.4549"
+ y="345.02151">bzr resolve</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="779.21564"
+ y="320.14914"
+ id="text4282"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ x="779.21564"
+ y="320.14914"
+ id="tspan3055">Автоопределение решенных</tspan><tspan
+ sodipodi:role="line"
+ x="779.21564"
+ y="332.14914"
+ id="tspan2692">конфликтов</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="784.65216"
+ y="375.57367"
+ id="text4288"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan4290"
+ sodipodi:role="line"
+ x="784.65216"
+ y="375.57367">bzr resolve foo.py</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="778.4129"
+ y="364.28137"
+ id="text4292"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan4294"
+ sodipodi:role="line"
+ x="778.4129"
+ y="364.28137">Снять пометку о конфликте</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="830.59387"
+ y="420.96985"
+ id="text4535"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4537"
+ x="830.59387"
+ y="420.96985">Публикация</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="781.75757"
+ y="507.81726"
+ id="text4616"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="781.75757"
+ y="507.81726"
+ id="tspan4618">bzr push sftp://host/myproject-fo1</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.17261"
+ y="482.57898"
+ id="text4620"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4622"
+ x="776.17261"
+ y="482.57898">Опубликовать ревизии </tspan><tspan
+ sodipodi:role="line"
+ x="776.17261"
+ y="494.57898"
+ id="tspan2742">удаленно</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="782.38531"
+ y="461.36774"
+ id="text4457"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ x="782.38531"
+ y="461.36774"
+ id="tspan4459">bzr push ../myproject-fo1</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.80035"
+ y="448.54938"
+ id="text4461"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4463"
+ x="776.80035"
+ y="448.54938">Опубликовать ревизии</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="782.40686"
+ y="553.90088"
+ id="text4467"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan8805"
+ sodipodi:role="line"
+ x="782.40686"
+ y="553.90088">bzr send</tspan><tspan
+ sodipodi:role="line"
+ x="782.40686"
+ y="564.97418"
+ id="tspan4473" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.13245"
+ y="529.0285"
+ id="text4475"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ x="776.13245"
+ y="529.0285"
+ id="tspan3063">Отправить почтой директиву</tspan><tspan
+ sodipodi:role="line"
+ x="776.13245"
+ y="541.0285"
+ id="tspan3042">объединения</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="783.03967"
+ y="647.42365"
+ id="text4481"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4483"
+ x="783.03967"
+ y="647.42365">bzr export ../myproject-dist/</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.80042"
+ y="622.18542"
+ id="text4485"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan4610"
+ sodipodi:role="line"
+ x="776.80042"
+ y="622.18542">Экспортировать текущую </tspan><tspan
+ sodipodi:role="line"
+ x="776.80042"
+ y="634.18542"
+ id="tspan2736">ревизию как каталог</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="782.56512"
+ y="695.45319"
+ id="text4521"
+ sodipodi:linespacing="110%"><tspan
+ sodipodi:role="line"
+ id="tspan4523"
+ x="782.56512"
+ y="695.45319">bzr export ../myproject-dist.zip</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.32587"
+ y="668.63489"
+ id="text4525"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan4612"
+ sodipodi:role="line"
+ x="776.32587"
+ y="668.63489">Экспортировать текущую </tspan><tspan
+ sodipodi:role="line"
+ x="776.32587"
+ y="680.63489"
+ id="tspan2732">ревизию как архив</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:10.0666666px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:110.00000238%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="780.99316"
+ y="600.0423"
+ id="text2448"
+ sodipodi:linespacing="110%"><tspan
+ id="tspan2450"
+ sodipodi:role="line"
+ x="780.99316"
+ y="600.0423">bzr send -o ../base.patch</tspan><tspan
+ sodipodi:role="line"
+ x="780.99316"
+ y="611.1156"
+ id="tspan2452" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="776.71875"
+ y="575.16986"
+ id="text2454"
+ sodipodi:linespacing="100%"><tspan
+ id="tspan2456"
+ sodipodi:role="line"
+ x="776.71875"
+ y="575.16986">Создать директиву</tspan><tspan
+ sodipodi:role="line"
+ x="776.71875"
+ y="587.16986"
+ id="tspan2738">объединения</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:30.5;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="144.32812"
+ y="64.254639"
+ id="text2774"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan2776"
+ x="144.32812"
+ y="64.254639">Bazaar </tspan></text>
+ <g
+ style="display:inline"
+ id="g3653"
+ transform="matrix(0.6461515,0,0,0.6526216,160.93614,144.01237)"
+ inkscape:export-filename="/home/matt/Projects/Ubuntu/Bazaar Website/bzr icon 64.png"
+ inkscape:export-xdpi="45.012665"
+ inkscape:export-ydpi="45.012665">
+ <path
+ id="path2749"
+ d="M -143.51431,-75.4275 C -158.48768,-90.57687 -171.17625,-103.66019 -171.7111,-104.50153 C -174.63909,-109.10738 -172.34363,-112.16647 -143.7155,-141.81059 C -119.96256,-166.4065 -114.08422,-171.84722 -111.26302,-171.84722 C -108.45655,-171.84722 -102.57922,-166.49332 -79.566158,-142.97326 C -59.704508,-122.67403 -51.314608,-113.24681 -51.314608,-111.22876 C -51.314608,-107.03298 -109.21126,-47.88319 -113.31814,-47.88319 C -115.49463,-47.88319 -123.57621,-55.25503 -143.51431,-75.4275 z "
+ style="opacity:1;fill:#fce94f;fill-opacity:1;stroke:#fce94f;stroke-width:4;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline" />
+ <path
+ id="path2721"
+ d="M -118.75152,-74.850683 C -119.22012,-75.319283 -119.60352,-85.958443 -119.60352,-98.493313 L -119.60352,-121.28395 L -124.85215,-121.28395 C -131.2088,-121.28395 -131.22918,-121.19503 -121.27316,-136.90004 C -116.77235,-143.99978 -113.38241,-148.09169 -112.19584,-147.85705 C -110.34853,-147.49175 -95.321883,-124.90849 -95.321883,-122.4975 C -95.321883,-121.83004 -97.640303,-121.28395 -100.47393,-121.28395 C -103.84689,-121.28395 -105.87693,-120.6299 -106.35276,-119.38989 C -107.55959,-116.24495 -103.45251,-106.32746 -97.296233,-97.520823 C -90.988133,-88.497013 -90.461803,-86.665103 -93.461883,-84.175253 C -95.128693,-82.791933 -96.185063,-83.268713 -100.25177,-87.239733 C -102.90055,-89.826193 -105.46285,-91.547323 -105.94572,-91.064423 C -106.42862,-90.581523 -106.8237,-86.544203 -106.8237,-82.092573 L -106.8237,-73.998703 L -112.36162,-73.998703 C -115.40746,-73.998703 -118.28294,-74.382103 -118.75152,-74.850683 z "
+ style="opacity:1;fill:#c4a000;fill-opacity:1;stroke:#c4a000;display:inline" />
+ <path
+ id="path2727"
+ d="M -120.75152,-76.85072 C -121.22012,-77.31932 -121.60352,-87.95848 -121.60352,-100.49335 L -121.60352,-123.28399 L -126.85215,-123.28399 C -133.2088,-123.28399 -133.22918,-123.19507 -123.27316,-138.90007 C -118.77235,-145.99981 -115.38241,-150.09172 -114.19584,-149.85708 C -112.34853,-149.49178 -97.321888,-126.90852 -97.321888,-124.49754 C -97.321888,-123.83008 -99.640308,-123.28399 -102.47393,-123.28399 C -105.84689,-123.28399 -107.87693,-122.62994 -108.35276,-121.38993 C -109.55959,-118.24499 -105.45251,-108.3275 -99.296238,-99.52086 C -92.988138,-90.49705 -92.461808,-88.66514 -95.461888,-86.17529 C -97.128698,-84.79197 -98.185068,-85.26875 -102.25177,-89.23977 C -104.90055,-91.82623 -107.46285,-93.54736 -107.94572,-93.06446 C -108.42862,-92.58156 -108.8237,-88.54424 -108.8237,-84.09261 L -108.8237,-75.99874 L -114.36162,-75.99874 C -117.40746,-75.99874 -120.28294,-76.38214 -120.75152,-76.85072 z "
+ style="opacity:1;fill:#555753;fill-opacity:1;stroke:#2e3436;stroke-opacity:1;display:inline" />
+ <path
+ d="M -143.51431,-75.4275 C -158.48768,-90.57687 -171.17625,-103.66019 -171.7111,-104.50153 C -174.63909,-109.10738 -172.34363,-112.16647 -143.7155,-141.81059 C -119.96256,-166.4065 -114.08422,-171.84722 -111.26302,-171.84722 C -108.45655,-171.84722 -102.57922,-166.49332 -79.566162,-142.97326 C -59.704512,-122.67403 -51.314612,-113.24681 -51.314612,-111.22876 C -51.314612,-107.03298 -109.21126,-47.88319 -113.31814,-47.88319 C -115.49463,-47.88319 -123.57621,-55.25503 -143.51431,-75.4275 z M -82.734602,-78.80831 C -63.284082,-98.78654 -53.870592,-109.3496 -53.870592,-111.19708 C -53.870592,-114.35673 -108.28764,-170.68595 -111.26979,-170.61328 C -113.31427,-170.56346 -167.39892,-115.6112 -169.81635,-111.12752 C -171.82156,-107.40842 -170.53236,-105.76188 -145.24612,-79.74648 C -117.66227,-51.36719 -115.36413,-49.16116 -113.38369,-49.16116 C -112.40192,-49.16116 -98.609822,-62.50237 -82.734602,-78.80831 z "
+ style="opacity:1;fill:#555753;fill-opacity:1;stroke:#2e3436;stroke-width:2;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline"
+ id="path2736" />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="146.57143"
+ y="97.808769"
+ id="text3409"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan3411"
+ x="146.57143"
+ y="97.808769">Карточка быстрого старта</tspan></text>
+ <g
+ id="g12314"
+ transform="translate(3.6699829,1.7472534)"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ sodipodi:linespacing="100%"
+ id="text8833"
+ y="527.43823"
+ x="297.99408"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:#333333;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;font-family:Bitstream Vera Sans"
+ y="527.43823"
+ x="297.99408"
+ id="tspan8835"
+ sodipodi:role="line">Поддерживаемые префиксы URL</tspan></text>
+ <g
+ id="g12288"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="299.33002"
+ y="547.94214"
+ id="text8837"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan8841"
+ x="299.33002"
+ y="547.94214">aftp://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8843"
+ x="299.33002"
+ y="565.94214">bzr://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="583.94214"
+ id="tspan10799">bzr+ssh://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="601.94214"
+ id="tspan3050">file://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8849"
+ x="299.33002"
+ y="619.94214">ftp:// </tspan><tspan
+ sodipodi:role="line"
+ id="tspan8851"
+ x="299.33002"
+ y="637.94214">http://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8853"
+ x="299.33002"
+ y="655.94214">https://</tspan><tspan
+ sodipodi:role="line"
+ x="299.33002"
+ y="673.94214"
+ id="tspan10797" /><tspan
+ sodipodi:role="line"
+ id="tspan8855"
+ x="299.33002"
+ y="691.94214">sftp://</tspan><tspan
+ sodipodi:role="line"
+ id="tspan8857"
+ x="299.33002"
+ y="709.94214" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;opacity:1;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="379.22845"
+ y="547.94214"
+ id="text12260"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan12262"
+ x="379.22845"
+ y="547.94214">Доступ, используя активный FTP</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="565.94214"
+ id="tspan12264">Быстрый доступ, используя сервер Bazaar</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="583.94214"
+ id="tspan12270">Быстрый доступ через SSH, используя сервер Bazaar</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="601.94214"
+ id="tspan3048">Доступ, используя файловую систему (по-умолчанию)</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="619.94214"
+ id="tspan12272">Доступ, используя пассивный FTP</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="637.94214"
+ id="tspan12274">Доступ для чтения веток размещенных в интернете</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="655.94214"
+ id="tspan3058">Доступ через SSL для чтения веток размещенных</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="673.94214"
+ id="tspan3068">в интернете</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="691.94214"
+ id="tspan12282">Доступ, используя SFTP (большинство SSH серверов</tspan><tspan
+ sodipodi:role="line"
+ x="379.22845"
+ y="709.94214"
+ id="tspan3072">предоставляют SFTP)</tspan></text>
+ </g>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:#333333;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="302.50391"
+ y="320.09448"
+ id="text4624"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan4626"
+ x="302.50391"
+ y="320.09448"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;font-family:Bitstream Vera Sans">Концепции</tspan></text>
+ <text
+ transform="scale(0.9968065,1.0032037)"
+ xml:space="preserve"
+ style="font-size:12.03844452px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="455.10013"
+ y="340.18164"
+ id="text12146"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan12148"
+ x="455.10013"
+ y="340.18164">направление разработки проекта</tspan><tspan
+ sodipodi:role="line"
+ x="455.10013"
+ y="358.23932"
+ id="tspan12150">каталог под контролем версий </tspan><tspan
+ sodipodi:role="line"
+ x="455.10013"
+ y="376.29697"
+ id="tspan12152">хранилище ревизий Bazaar</tspan><tspan
+ sodipodi:role="line"
+ x="455.10013"
+ y="394.35464"
+ id="tspan12156">версия исходного кода зафиксированная</tspan><tspan
+ id="tspan2710"
+ sodipodi:role="line"
+ x="455.10013"
+ y="412.41229">в хранилище</tspan><tspan
+ sodipodi:role="line"
+ x="455.10013"
+ y="430.46997"
+ id="tspan12158">именованная ревизия</tspan><tspan
+ sodipodi:role="line"
+ x="455.10013"
+ y="448.52765"
+ id="tspan12160">ветки имеющие общего предка</tspan><tspan
+ sodipodi:role="line"
+ x="455.10013"
+ y="466.5853"
+ id="tspan12164">операция применения к ветке всех </tspan><tspan
+ id="tspan3886"
+ sodipodi:role="line"
+ x="455.10013"
+ y="484.64297">изменений сделанных в другой ветке</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:150%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ x="303"
+ y="341.21167"
+ id="text12400"
+ sodipodi:linespacing="150%"><tspan
+ sodipodi:role="line"
+ id="tspan12402"
+ x="303"
+ y="341.21167">Ветка:</tspan><tspan
+ sodipodi:role="line"
+ x="303"
+ y="359.21167"
+ id="tspan12404">Рабочее дерево:</tspan><tspan
+ sodipodi:role="line"
+ x="303"
+ y="377.21167"
+ id="tspan12406">Репозиторий:</tspan><tspan
+ sodipodi:role="line"
+ x="303"
+ y="395.21167"
+ id="tspan12408">Ревизия:</tspan><tspan
+ sodipodi:role="line"
+ x="303"
+ y="413.21167"
+ id="tspan12410" /><tspan
+ sodipodi:role="line"
+ x="303"
+ y="431.21167"
+ id="tspan12412">Метка:</tspan><tspan
+ sodipodi:role="line"
+ x="303"
+ y="449.21167"
+ id="tspan12414">Родственные ветки:</tspan><tspan
+ sodipodi:role="line"
+ x="303"
+ y="467.21167"
+ id="tspan12416">Объединение:</tspan><tspan
+ sodipodi:role="line"
+ x="303"
+ y="485.21167"
+ id="tspan12418" /></text>
+ <g
+ id="g6327"
+ transform="translate(6.5601196,0)"
+ style="fill:#333333;fill-opacity:1">
+ <text
+ sodipodi:linespacing="100%"
+ id="text6294"
+ y="50.289795"
+ x="645.77582"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;opacity:1;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="50.289795"
+ x="645.77582"
+ id="tspan6296"
+ sodipodi:role="line">Дополнительная информация</tspan></text>
+ <g
+ id="g6320"
+ style="fill:#333333;fill-opacity:1"
+ transform="translate(-142.82842,0)">
+ <text
+ xml:space="preserve"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans Mono"
+ x="787.72699"
+ y="76.095581"
+ id="text6298"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan6300"
+ x="787.72699"
+ y="76.095581">bzr help</tspan></text>
+ <a
+ id="a6316"
+ style="fill:#333333;fill-opacity:1"
+ xlink:href="http://bazaar.canonical.com">
+ <text
+ sodipodi:linespacing="100%"
+ id="text6302"
+ y="97.901367"
+ x="787.79535"
+ style="font-size:20px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#333333;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;font-family:Bitstream Vera Sans"
+ xml:space="preserve"><tspan
+ y="97.901367"
+ x="787.79535"
+ id="tspan6304"
+ sodipodi:role="line">http://bazaar.canonical.com</tspan></text>
+ </a>
+ </g>
+ </g>
+ </g>
+</svg>
diff --git a/doc/ru/_templates/layout.html b/doc/ru/_templates/layout.html
new file mode 100644
index 0000000..04235ef
--- /dev/null
+++ b/doc/ru/_templates/layout.html
@@ -0,0 +1,8 @@
+{% extends "!layout.html" %}
+
+{% block rootrellink %}
+<li><a href="http://bazaar.canonical.com/">
+ <img src="{{ pathto("_static/bzr icon 16.png", 1) }}" /> Главная</a>&nbsp;|&nbsp;</li>
+<a href="http://doc.bazaar.canonical.com/ru/">Документация</a>&nbsp;|&nbsp;</li>
+{{ super() }}
+{% endblock %}
diff --git a/doc/ru/conf.py b/doc/ru/conf.py
new file mode 100644
index 0000000..edce830
--- /dev/null
+++ b/doc/ru/conf.py
@@ -0,0 +1,105 @@
+# -*- coding: utf-8 -*-
+#
+# Bazaar documentation build configuration file, created by
+# sphinx-quickstart on Tue Jul 21 17:04:52 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+sys.path = [os.path.abspath('../..')] + sys.path
+
+# Most of the configuration for Bazaar docs is defined here ...
+from bzrlib.doc_generate.conf import *
+
+
+## Configuration specific to this site ##
+
+# The locale code for this documentation set
+bzr_locale = 'ru'
+
+# Translations & supporting helper function
+bzr_titles = {
+ u'Table of Contents (%s)': u'Содержание (%s)',
+ u'Bazaar User Guide': None,
+ u'Bazaar User Reference': None,
+ u'Bazaar Release Notes': None,
+ u'Bazaar Upgrade Guide': None,
+ u'Bazaar in five minutes': u'Базар за пять минут',
+ u'Bazaar Tutorial': u'Большой учебник',
+ u'Using Bazaar With Launchpad': u'Использование Bazaar с Launchpad',
+ u'Centralized Workflow Tutorial': u'Работа в централизованном стиле',
+ }
+def bzr_title(s):
+ return bzr_titles.get(s) or s
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+language = bzr_locale
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+html_short_title = bzr_title(u"Table of Contents (%s)") % (release,)
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {'index': 'index.html'}
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'bzr-%s' % (bzr_locale,)
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+bzr_documents = [
+ # Manuals
+ #('user-guide/index', 'bzr-%s-user-guide' % (bzr_locale,),
+ # bzr_title(u'Bazaar User Guide'), bzr_team, 'manual'),
+ #('user-reference/bzr_man', 'bzr-%s-user-reference' % (bzr_locale,),
+ # bzr_title(u'Bazaar User Reference'), bzr_team, 'manual'),
+ #('release-notes/NEWS', 'bzr-%s-release-notes' % (bzr_locale,),
+ # bzr_title(u'Bazaar Release Notes'), bzr_team, 'manual'),
+ #('upgrade-guide/index', 'bzr-%s-upgrade-guide' % (bzr_locale,),
+ # bzr_title(u'Bazaar Upgrade Guide'), bzr_team, 'manual'),
+ # Tutorials
+ ('mini-tutorial/index', 'bzr-%s-tutorial-mini' % (bzr_locale,),
+ bzr_title(u'Bazaar in five minutes'), bzr_team, 'howto'),
+ ('tutorials/tutorial', 'bzr-%s-tutorial' % (bzr_locale,),
+ bzr_title(u'Bazaar Tutorial'), bzr_team, 'howto'),
+ #('tutorials/using_bazaar_with_launchpad',
+ # 'bzr-%s-tutorial-with-launchpad' % (bzr_locale,),
+ # bzr_title(u'Using Bazaar With Launchpad'), bzr_team, 'howto'),
+ #('tutorials/centralized_workflow',
+ # 'bzr-%s-tutorial-centralized' % (bzr_locale,),
+ # bzr_title(u'Centralized Workflow Tutorial'), bzr_team, 'howto'),
+]
+
+latex_documents = [
+ (start, target+'.tex', title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+texinfo_documents = [
+ (start, target, title, author, doc_class)
+ for start, target, title, author, doc_class in bzr_documents
+ ]
+
+
+# List of documents that shouldn't be included in the build.
+unused_docs = [
+ # Subtopics that get included
+ 'upgrade-guide/overview',
+ 'upgrade-guide/data_migration',
+ 'upgrade-guide/tips_and_tricks',
+ 'user-guide/branching_a_project',
+ 'user-guide/core_concepts',
+ 'user-guide/introducing_bazaar',
+ 'user-guide/specifying_revisions',
+ 'user-guide/stacked',
+ 'user-guide/using_checkouts',
+ 'user-guide/zen',
+ # Plain-style documentation generation stuff
+ 'user-guide/index-plain',
+]
+
diff --git a/doc/ru/index.txt b/doc/ru/index.txt
new file mode 100644
index 0000000..8ef9163
--- /dev/null
+++ b/doc/ru/index.txt
@@ -0,0 +1,39 @@
+=================================
+Главный каталог документов Bazaar
+=================================
+
+Последняя версия этих документов доступа со страницы документации
+на сайте Bazaar, <http://doc.bazaar.canonical.com/ru/>.
+
+Основная документация
+=====================
+
+.. toctree::
+ :maxdepth: 1
+
+ user-guide/index
+ quick-reference/index
+ mini-tutorial/index
+ tutorials/tutorial
+ tutorials/using_bazaar_with_launchpad
+ tutorials/centralized_workflow
+
+
+Ссылки в сети
+=============
+
+* `Руководство по миграции <http://doc.bazaar.canonical.com/migration/en/>`_
+ |--| для команд переносящих историю с других систем контроля версий
+
+* `Словарь терминов <http://wiki.bazaar.canonical.com/BzrGlossary>`_ (англ.),
+ см. также `русскую версию`__
+
+__ http://groups.google.com/group/ru_bzr/web/%D0%B3%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9
+
+* `Часто задаваемые вопросы <https://answers.launchpad.net/bzr>`_ (англ.)
+
+
+.. |--| unicode:: U+2014
+
+..
+ vim: ft=rst tw=74 ai
diff --git a/doc/ru/mini-tutorial/index.txt b/doc/ru/mini-tutorial/index.txt
new file mode 100644
index 0000000..2e66f9c
--- /dev/null
+++ b/doc/ru/mini-tutorial/index.txt
@@ -0,0 +1,289 @@
+======================
+Bazaar за пять минут
+======================
+
+.. contents::
+ Содержание
+
+Введение
+========
+
+Bazaar |--| это распределенная система контроля версий, которая упрощает
+совместную работу над программными проектами.
+
+В течении следующих пяти минут, вы узнаете как начать контролировать версии
+ваших файлов, как вносить изменения, проверять вашу работу, публиковать её и
+отправлять для объединения с главной веткой проекта.
+
+Если вы предпочитаете более подробное введение, обратитесь к разделу
+`Узнать больше`_.
+
+Установка
+=========
+
+Это руководство не описывает как установить Bazaar, потому что обычно
+это очень легко. Инструкции по установке вы найдете тут:
+
+- **GNU/Linux:** скорее всего Bazaar уже присутствует в вашем дистрибутиве GNU/Linux.
+- **Windows:** `инструкции по установке для Windows`_.
+- **Mac OS X:** `инструкции по установке для Mac OS X`_.
+
+Для других платформ и для установки из исходных кодов, обратитесь к страницам
+Загрузка_ и Установка_.
+
+.. _инструкции по установке для Windows: http://wiki.bazaar.canonical.com/WindowsDownloads
+.. _инструкции по установке для Mac OS X: http://wiki.bazaar.canonical.com/MacOSXBundle
+.. _Загрузка: http://wiki.bazaar.canonical.com/Download
+.. _Установка: http://wiki.bazaar.canonical.com/InstallationFaq
+
+Представьтесь
+=============
+
+Прежде чем начать работать, было бы неплохо сообщить Bazaar кто вы такой.
+В этом случае ваша работа будет корректно идентифицирована в истории ревизий.
+
+Используя ваше имя и адрес электронной почты, вместо данных Васи Пупкина,
+наберите::
+
+ $ bzr whoami "Vasya Pupkin <vasya.pupkin@mail.ru>"
+
+В этот момент Bazaar создаст или исправит файл настроек, включив в него ваше
+имя и адрес электронной почты.
+
+Теперь, проверьте правильно ли сохранены ваши имя и адрес::
+
+ $ bzr whoami
+ Vasya Pupkin <vasya.pupkin@mail.ru>
+
+
+Начинаем контролировать версии файлов
+=====================================
+
+Давайте создадим каталог и несколько файлов для использования с Bazaar::
+
+ $ mkdir myproject
+ $ cd myproject
+ $ mkdir subdirectory
+ $ touch test1.txt test2.txt test3.txt subdirectory/test4.txt
+
+**Замечание для пользователей Windows:** используйте Windows Explorer
+для создания ваших каталогов, затем нажимайте правую кнопку мыши
+в этих каталогах и выбирайте ``Новый файл``, чтобы создать ваши файлы.
+
+Теперь дадим Bazaar возможность инициализировать свои данные в каталоге вашего
+проекта::
+
+ $ bzr init
+
+Если всё выглядит так, как будто ничего не случилось |--| не волнуйтесь. Bazaar
+создал ветку_, в которой он будет хранить рабочие файлы и историю их изменений.
+
+.. _ветку: http://wiki.bazaar.canonical.com/Branch
+
+Следующий шаг |--| сказать Bazaar какие файлы вы хотите контролировать. Команда
+``bzr add`` рекурсивно добавит все файлы в проект::
+
+ $ bzr add
+ added subdirectory
+ added test1.txt
+ added test2.txt
+ added test3.txt
+ added subdirectory/test4.txt
+
+Далее, нужно сохранить текущее состояние ваших файлов зафиксировав их в вашей
+ветке. Добавьте сообщение объясняющее зачем вы сделали фиксацию::
+
+ $ bzr commit -m "Импортируем файлы"
+
+Т.к. Bazaar это распределенная система контроля версий, здесь нет необходимости
+соединяться с центральным сервером для выполнения фиксации. Вместо этого,
+Bazaar сохраняет вашу ветку и все её фиксации внутри каталога с которым вы
+работаете; обратите внимание на подкаталог ``.bzr``.
+
+
+Вносим изменения в файлы
+========================
+
+Давайте изменим какой-либо файл и зафиксируем это изменение в вашей ветке.
+
+Отредактируйте ``test1.txt`` в своем любимом редакторе и затем посмотрите на
+сделанные изменения::
+
+ $ bzr diff
+ === modified file 'test1.txt'
+ --- test1.txt 2007-10-08 17:56:14 +0000
+ +++ test1.txt 2007-10-08 17:46:22 +0000
+ @@ -0,0 +1,1 @@
+ +test test test
+
+Зафиксируйте вашу работу в ветке Bazaar::
+
+ $ bzr commit -m "Добавлена первая строка текста"
+ Committed revision 2.
+
+
+Просматриваем журнал изменений
+==============================
+
+Вы можете увидеть историю вашей ветки просмотрев её журнал::
+
+ $ bzr log
+ ------------------------------------------------------------
+ revno: 2
+ committer: Vasya Pupkin <vasya.pupkin@mail.ru>
+ branch nick: myproject
+ timestamp: Mon 2007-10-08 17:56:14 +0000
+ message:
+ Добавлена первая строка текста
+ ------------------------------------------------------------
+ revno: 1
+ committer: Vasya Pupkin <vasya.pupkin@mail.ru>
+ branch nick: myproject
+ timestamp: Mon 2006-10-08 17:46:22 +0000
+ message:
+ Импортируем файлы
+
+
+Публикуем ветку через SFTP
+==========================
+
+Есть несколько способов опубликовать вашу ветку. Если у вас уже есть SFTP
+сервер или вам несложно его настроить, вы можете опубликовать свою ветку через
+него.
+
+В противном случае, переходите к следующему разделу, чтобы опубликовать ветку
+на Launchpad_ |--| бесплатном хостинге для Bazaar.
+
+.. _Launchpad: https://launchpad.net/
+
+Предположим, что вы хотите опубликовать свою ветку на
+``www.example.com/myproject``::
+
+ $ bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject
+ 2 revision(s) pushed.
+
+Bazaar создаст каталог ``myproject`` на удаленном сервере и поместит в него
+вашу ветку.
+
+Теперь любой желающий сможет создать свою собственную копию вашей ветки,
+выполнив::
+
+ $ bzr branch http://www.example.com/myproject
+
+**Замечание:** чтобы использовать SFTP, может понадобиться установить
+``paramiko`` и ``pyCrypto``. За подробностями обращайтесь к
+http://wiki.bazaar.canonical.com/InstallationFaq.
+
+
+Публикация ветки на Launchpad
+=============================
+
+Launchpad это набор инструментов для разработки и размещения проектов
+свободного программного обеспечения. Вы можете использовать его для публикации
+своей ветки.
+
+Если у вас нет учетной записи Launchpad, следуйте
+`руководству по получению учетной записи`_ и `зарегистрируйте SSH ключ`_
+в своей новой учетной записи.
+
+.. _руководству по получению учетной записи: https://help.launchpad.net/CreatingYourLaunchpadAccount
+.. _зарегистрируйте SSH ключ: https://launchpad.net/people/+me/+editsshkeys
+
+Заменив ``vasya.pupkin`` на ваше имя пользователя Launchpad, выполните::
+
+ $ bzr push bzr+ssh://vasya.pupkin@bazaar.launchpad.net/~vasya.pupkin/+junk/myproject
+
+**Замечание:** ``+junk`` означает что ветка не связана с каким-либо проектом на
+Launchpad.
+
+Теперь любой желающий сможет создать свою собственную копию вашей ветки,
+выполнив::
+
+ $ bzr branch http://bazaar.launchpad.net/~vasya.pupkin/+junk/myproject
+
+Вы также сможете видеть информацию по вашей ветке, включая журнал изменений, по
+адресу https://code.launchpad.net/people/+me/+junk/myproject
+
+
+Создаем собственную копию другой ветки
+======================================
+
+Чтобы работать с чьим-либо кодом, вы можете создать собственную копию чужой
+ветки. Давайте возьмем реальный пример |--| GTK интерфейс для Bazaar::
+
+ $ bzr branch http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk bzr-gtk.vasya
+ Branched 292 revision(s).
+
+Bazaar загрузит все файлы и полный журнал изменений из основной ветки проекта
+bzr-gtk и создаст копию с именем bzr-gtk.vasya.
+
+Теперь у вас есть собственная копия ветки и вы можете фиксировать изменения и с
+сетевым подключением и без него. Вы можете поделиться своей веткой в любое
+время, опубликовав ветку. И если команда разработчиков bzr-gtk захочет
+использовать вашу работу, Bazaar легко позволит им объединить вашу ветку
+обратно в их основную ветку.
+
+Обновляем ветку изменениями из основной ветки
+=============================================
+
+Пока вы фиксируете изменения в вашей ветке, другие люди, скорее всего, так же
+продолжают фиксировать код в родительской ветке.
+
+Чтобы быть уверенным что ваша ветка содержит последние изменения, вам следует
+объединить родительскую ветку с вашей личной::
+
+ $ bzr merge
+ Merging from saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
+ All changes applied successfully.
+
+Проверьте что изменилось::
+
+ $ bzr diff
+
+Если изменения вас устраивают, вы можете зафиксировать их в своей ветке::
+
+ $ bzr commit -m "Изменения из основной ветки"
+ Committed revision 295.
+
+
+Объединяем свои изменения с родительской веткой
+===============================================
+
+После того как вы поработали в своей ветке bzr-gtk, вы можете захотеть
+отправить ваши изменения для включения в проект. Простейший способ заключается
+в использовании директивы объединения.
+
+Директива объединения |--| это машиночитаемый запрос на осуществление
+конкретного объединения. Обычно он содержит обзор изменений, которые
+планируется объединить. Также директива объединения содержит либо необходимые
+ревизии, либо указывает на ветку где они могут быть получены.
+
+Заменив ``mycode.patch``, создайте свою директиву объединения::
+
+ $ bzr send -o mycode.patch
+ Using saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
+
+Теперь вы можете отправить директиву объединения по электронной почте
+в проект bzr-gtk. Если разработчики bzr-gtk захотят, то смогут использовать
+эту директиву для включения вашей работы в основную ветку.
+
+
+Узнать больше
+=============
+
+Больше информации о Bazaar вы найдете в
+`Руководстве пользователя Bazaar <../user-guide/index.html>`_.
+
+Чтобы узнать больше о Bazaar из командой строки::
+
+ $ bzr help
+
+Чтобы узнать основные команды Bazaar::
+
+ $ bzr help commands
+
+Чтобы узнать о теме или команде "foo"::
+
+ $ bzr help foo
+
+.. |--| unicode:: U+2014
diff --git a/doc/ru/quick-reference/index.txt b/doc/ru/quick-reference/index.txt
new file mode 100644
index 0000000..aae1ae1
--- /dev/null
+++ b/doc/ru/quick-reference/index.txt
@@ -0,0 +1,6 @@
+Карточка быстрого старта
+========================
+
+* `PDF <../_static/ru/bzr-ru-quick-reference.pdf>`_
+* `PNG <../_static/ru/bzr-ru-quick-reference.png>`_
+* `SVG <../_static/ru/bzr-ru-quick-reference.svg>`_
diff --git a/doc/ru/tutorials/centralized_workflow.txt b/doc/ru/tutorials/centralized_workflow.txt
new file mode 100644
index 0000000..a693750
--- /dev/null
+++ b/doc/ru/tutorials/centralized_workflow.txt
@@ -0,0 +1,319 @@
+===============================
+Работа в централизованном стиле
+===============================
+
+.. sectnum::
+
+
+Обзор
+=====
+
+Этот документ описывает один из возможных подходов к использованию
+Bazaar_. А именно, использование распределенной системы контроля версий
+Bazaar_, в централизованном стиле. Bazaar_ разработана, что бы быть гибкой
+и допускать различные подходы к работе, начиная от полностью
+децентрализованного, до практически централизованного. Подход описанный
+здесь позволяет новым пользователям проще вникнуть в более продвинутое
+использование Bazaar_ и смешивать централизованные и децентрализованные
+операции.
+
+В общем случае, данный документ интересен для пользователей переходящих с
+централизованных систем, таких как CVS, или Subversion. В таких системах
+обычно есть единственный центральный сервер на котором хранится код
+проекта и участники команды работают над этим кодом, синхронизируя свою
+работу. Такой режим так же подходит для разработчика-одиночки,
+работающего на нескольких различных машинах.
+
+.. _Bazaar: http://bazaar.canonical.com
+
+.. contents::
+ Содержание
+
+
+Начальные установки
+===================
+
+В самом начале, для более удобной работы с Bazaar_, желательно осуществить
+достаточно простые шаги по настройке.
+
+
+Настройка e-mail пользователя
+-----------------------------
+
+Строка идентифицирующая пользователя сохраняется при каждой фиксации. Хотя
+она не обязательно должна быть аккуратной или уникальной она будет
+использоваться в сообщениях журнала и аннотациях, таким образом лучше что
+бы она была похожа на что-то реальное.
+
+::
+
+ % bzr whoami "Иван Пупкин <ivan@pupkin.ru>"
+
+
+Настройка локального репозитория
+--------------------------------
+
+В общем случае ветки Bazaar_ копируют полную историю изменений вместе с
+собой, что, кстати, позволяет работать в полностью децентрализованном
+стиле. Как оптимизация для связанных веток возможно объединять их
+хранилища таким образом, что отпадает необходимость в копировании полной
+истории изменений при создании новой ветки.
+
+Лучший способ сделать это - создать `Разделяемый репозиторий`_. В общем
+случае, ветки будут разделять хранилище если они находятся в подкаталоге
+этого репозитория. Давайте создадим `Разделяемый репозиторий`_ в нашем
+домашнем каталоге и таким образом все ветки которые мы будем создавать
+под ним будут разделять хранилище истории.
+
+::
+
+ % bzr init-repo --trees ~
+
+
+Настройка удаленного репозитория
+--------------------------------
+
+Во многих случаях нужно создавать место где данные хранятся отдельно от
+рабочего каталога. Такой подход необходим для централизованных систем
+(CVS/SVN). Обычно эти каталоги находятся на различных машинах, хотя и не
+всегда. На самом деле это достаточно хороший подход, особенно в рабочей
+среде. Так как здесь существует центральная точка, где могут быть сохранены
+все данные и даже если что-то случится с машиной разработчика
+зафиксированная работа не будет потеряна.
+
+Давайте создадим разделяемое место для нашего проекта на удаленной машине
+и назовем его ``centralhost``. Мы снова используем `Разделяемый
+репозиторий`_ для оптимизации использования дисков.
+
+::
+
+ % bzr init-repo --no-trees sftp://centralhost/srv/bzr/
+
+Можно рассматривать этот шаг как похожий на установку CVSROOT, или
+репозитория Subversion. Опция ``--no-trees`` указывает Bazaar не
+создавать рабочий каталог в репозитории. Нам это подходит, т.к. никто
+не будет напрямую что-то изменять на ветках в центральном репозитории.
+
+
+Миграция рабочего проекта в Bazaar
+==================================
+
+Теперь, когда у нас есть репозиторий давайте создадим проект под контролем
+версий. В большинстве случаев у вас уже есть какой-то код с которым вы
+работаете и для хранения которого вы хотели бы использовать Bazaar_. Если
+код изначально уже был под контролем версий существует много способов
+конвертировать проект в Bazaar_ без потери истории изменений. Но эти
+способы находятся вне тем рассматриваемых в данном документе. Смотрите
+`Отслеживание изменений на основной ветке`_ для некоторых способов (секция
+"Конвертирование и сохранение истории").
+
+.. _Отслеживание изменений на основной ветке: http://wiki.bazaar.canonical.com/TrackingUpstream
+
+..
+ TODO: На самом деле нам нужен другой документ для описания
+ конвертирования проекта. Но пока ссылка выше - это лучшее.
+
+
+Разработчик 1: Создание первой ревизии
+--------------------------------------
+
+Сначала нам нужно создать ветку в нашем удаленном репозитории, там где мы
+хотели бы хранить наш проект. Допустим, что у нас уже есть проект "sigil",
+который мы хотели бы хранить под контролем версий.
+
+::
+
+ % bzr init sftp://centralhost/srv/bzr/sigil
+
+Это можно рассматривать как ветку "HEAD" в терминах CVS, или как "trunk" в
+терминах Subversion. Назовем это веткой разработки ``dev``.
+
+Я предпочитаю работать в подкаталоге моего домашнего каталога, что бы
+избегать коллизий со всеми другими файлами которые в ней находятся. Также
+нам понадобится каталог для проекта где мы сможем хранить различные ветки
+проекта над которыми работаем.
+
+::
+
+ % cd ~
+ % mkdir work
+ % cd work
+ % mkdir sigil
+ % cd sigil
+ % bzr checkout sftp://centralhost/srv/bzr/sigil dev
+ % cd dev
+ % cp -ar ~/sigil/* .
+ % bzr add
+ % bzr commit -m "Первый импорт Sigil"
+
+Выше мы создали пустую ветку ``/sigil`` на ``centralhost`` и затем
+загрузили эту пустую ветку на нашу рабочую машину что бы добавить файлы из
+нашего старого проекта. Есть много способов настроить свой рабочий
+каталог, но шаги выше упрощают дальнейшую работу с ветками для работы
+над ошибками, или новыми функциями. И одна из наиболее сильных сторон
+Bazaar_ - это именно отличная работа с ветками.
+
+На этом этапе, т.к. мы создали рабочую копию (checkout) удаленной ветки,
+все фиксации которые будут сделаны в ``~/work/sigil/dev/`` будут
+автоматически сохранены и локально и на ``centralhost``.
+
+
+Разработчик N: Получение рабочей копии проекта
+----------------------------------------------
+
+Так как первый разработчик проделал всю работу по созданию проекта все
+остальные разработчики могут просто получить рабочую копию ветки. Хотя
+**они все еще должны следовать** разделам `Настройка e-mail пользователя`_ и
+`Настройка локального репозитория`_.
+
+Получим рабочую копию текущего дерева разработки::
+
+ % cd ~/work/sigil
+ % bzr checkout sftp://centralhost/srv/bzr/sigil dev
+
+Теперь, когда два человека имею рабочую копию
+``sftp://centralhost/srv/bzr/sigil`` будут ситуации когда одна из копий
+будет не синхронизирована с текущей версией. Во время фиксации Bazaar_
+проинформирует пользователя об этом и не допустит фиксации. Для получения
+последних изменений нужно использовать ``bzr update``. Эта команда может
+потребовать разрешения конфликтов если были изменены одни и те же файлы.
+
+
+Разработка на отдельных ветках
+==============================
+
+До этого момента все работали и фиксировали изменения на одну и ту же
+ветку. Это значит, что каждый должен периодически обновлять свою ветку и
+иметь дело с изменениями других разработчиков. Так же если один
+разработчик фиксирует что-то, что приводит к ошибкам, то после
+синхронизации эта проблема коснется каждого.
+
+Обычно лучше вести разработку на различных ветках и затем, как только
+изменения достаточно стабильны, интегрировать их обратно на основную
+ветку. Это одно из наибольших изменений по сравнению с работой в CVS/SVN.
+Обе эти системы позволяют работать с отдельными ветками, но их алгоритмы
+объединения достаточно слабы и поэтому с ними сложно держать все
+синхронизировано. Bazaar_ отслеживает что уже было объединено и может даже
+прикладывать изменения к файлам которые были переименованы.
+
+
+Создание и работа на новой ветке
+--------------------------------
+
+Мы бы хотели, что бы наши изменения были доступны другим даже если они
+пока еще не закончены. Таким образом мы создадим новую публичную ветку на
+``centralhost`` и будем отслеживать ее локально.
+
+::
+
+ % cd ~/work/sigil
+ % bzr branch sftp://centralhost/srv/bzr/sigil \
+ sftp://centralhost/srv/bzr/sigil/doodle-fixes
+ % bzr checkout sftp://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
+ % cd doodle-fixes
+
+Теперь у нас есть место где мы можем исправлять все ошибки для ``doodle``.
+И мы не будем прерывать никого кто работает над другими частями кода. Так
+как у нас есть рабочая копия (checkout) все фиксации которые мы делаем на
+``~/work/sigil/doodle-fixes/`` так же появятся и на ``centralhost``.
+[#nestedbranches]_ Также возможно, что бы два разработчика совместно
+работали над одной из этих веток, так же как они совместно работают над
+веткой ``dev``. [#cbranch]_
+
+.. [#nestedbranches] Может показаться странным иметь ветку в подкаталоге
+ другой ветки. Но это нормально, можно думать об этом как о
+ иерархическом пространстве имен где вложенная ветка является
+ производной от внешней ветки.
+
+.. [#cbranch] Когда используется множество независимых веток каждый раз
+ набирать полный URL занимает много времени. Мы рассматриваем различные
+ методы, что бы обойти это, например псевдонимы для веток и т.п. Но пока
+ плагин bzrtools_ предоставляет команду ``bzr cbranch``. Эта команда на
+ основе базовой ветки создает новую публичную ветку и рабочую копию этой
+ ветки всего одной командой. Конфигурирование ``cbranch`` не входит в
+ рамки описания этого документа, но финальная команда выглядит следующим
+ образом:
+
+ ::
+
+ % bzr cbranch dev my-feature-branch
+
+.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
+
+
+Объединение изменений обратно
+-----------------------------
+
+Когда решено что некоторые изменения из ``doodle-fixes`` готовы для
+объединения на основную ветку нужно просто сделать следующее::
+
+ % cd ~/work/sigil/dev
+ % bzr merge ../doodle-fixes
+
+Теперь изменения доступны на ветке ``dev``, но они пока еще не были
+зафиксированы. В этот момент нужно просмотреть финальные изменения и
+проверить, что код компилируется и проходят все тесты. Команды ``bzr
+status`` и ``bzr diff`` хорошие инструменты для этого. Так же нужно
+разрешить возможные конфликты. Bazaar_ не допустит фиксации пока не будут
+разрешены все конфликты. В этом случае вы случайно не зафиксируете маркеры
+конфликта. Команда ``bzr status`` покажет конфликты и изменения, или можно
+использовать ``bzr conflicts`` что бы увидеть только конфликты.
+Используйте ``bzr resolve file/name``, или ``bzr resolve --all`` как
+только конфликты были разрешены. [#resolve]_ Если существуют конфликты
+которые особенно сложно разрешить можно использовать команду ``bzr
+remerge``. Эта команда позволит использовать другие алгоритмы объединения
+и также позволит увидеть строки оригинального кода (``--show-base``).
+
+.. [#resolve] Некоторые системы позволяют разрешать конфликты как часть
+ процесса объединения. Мы обнаружили, что обычно проще разрешать
+ конфликты когда можно просматривать полное дерево, а не только
+ отдельные файлы. Это дает намного больше контекста и также позволяет
+ запускать тесты когда проблема будет решена.
+
+
+Рекомендации по созданию веток
+------------------------------
+
+Один из часто используемых способов работы с набором веток - это дать
+каждому разработчику свою собственную ветку и собственное место для работы
+на центральном сервере. Это можно сделать так::
+
+ % bzr branch sftp://centralhost/srv/bzr/sigil \
+ sftp://centralhost/srv/bzr/sigil/user-a
+ % bzr branch sftp://centralhost/srv/bzr/sigil \
+ sftp://centralhost/srv/bzr/sigil/user-b
+
+Это дает каждому разработчику собственную ветку для работы. И они смогут
+легко создать новые ветки с помощью [#cbranch]_
+::
+
+ % bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
+ sftp://centralhost/srv/bzr/sigil/user-a/feature
+ % cd ~/work/sigil
+ % bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
+
+
+Глоссарий
+=========
+
+Разделяемый репозиторий
+-----------------------
+
+Bazaar_ поддерживает концепцию "Разделяемый репозиторий". Эта концепция
+похожа на традиционные концепции репозиториев в других системах контроля
+версий, таких как CVS, или Subversion. Например, в Subversion у вас есть
+удаленный репозиторий, где хранится вся история и локально история не
+хранится, а хранится только рабочая копия файлов. Конечно "Разделяемый" в
+данном контексте значит, что он разделен между ветками. Он *может* быть
+разделен между людьми, но отдельные ветки также могут быть разделены между
+людьми.
+
+В Bazaar_ термин "Разделяемый репозиторий" - это место где несколько веток
+могут *разделять* их историю ревизий. Что бы поддерживать
+децентрализованную схему работы каждая ветка может хранить свою
+собственную историю ревизий. Но часто это не эффективно, т.к. зависимые
+ветки разделяют историю и они могут так же разделять и хранилище истории.
+
+
+..
+ vim: tw=74 ft=rst spell spelllang=en_us
diff --git a/doc/ru/tutorials/tutorial.txt b/doc/ru/tutorials/tutorial.txt
new file mode 100644
index 0000000..ef545c0
--- /dev/null
+++ b/doc/ru/tutorials/tutorial.txt
@@ -0,0 +1,591 @@
+.. Этот файл в формате ReStructuredText - он может быть отформатирован в HTML,
+.. или текст. В будущем планируется выделять примеры команд и автоматически
+.. тестировать их.
+
+.. Данный текст сначала был на Wiki
+.. http://bazaar.canonical.com/IntroductionToBzr
+.. но был перемещен в дерево исходного кода что бы синхронизироваться
+.. с исходным кодом и возможно автоматически тестироваться.
+
+==============
+Учебник Bazaar
+==============
+
+Текущая версия для bzr-0.91, 2007-08
+
+
+Введение
+========
+
+Если вы уже знакомы с распределенными системами контроля версий, то можете
+сразу перейти к "Представляемся Bazaar". Если, с другой стороны, вы знакомы с
+системами контроля версий, но не знакомы с распределенными системами, тогда
+стоит начать с "Чем отличаются распределенные системы". Иначе, возьмите кофе
+или чай, расположитесь поудобнее и продолжим чтение.
+
+Назначение контроля версий
+==========================
+
+Есть шансы, что вы уже работали с какими-либо текстовыми данными -- исходниками
+программ, Web-сайтами, или конфигурационными файлами с которыми имеют дело
+администраторы систем Unix в /etc. Также есть хорошие шансы, что вы делали
+ошибки, которые вызывали потом глубокое сожаление. Возможно вы удалили
+конфигурационный файл для вашего почтового сервера, или повредили исходный код
+любимого проекта. Не важно что конкретно случилось, но вы просто удалили важную
+информацию которую вы безнадежно хотели бы вернуть. Если такое когда либо
+случалось с вами, то вы возможно готовы для Bazaar.
+
+Системы контроля версий, такие как Bazaar дают возможность отслеживать
+изменения для каталога, который они изменяют в нечто более сложное, что
+называется **ветка**. Ветка не только сохраняет то как каталог выглядит в
+данный момент, но также как он выглядел в различные моменты в прошлом. Затем,
+когда вы сделаете что-то, что бы вы не хотели делать, вы сможете восстановить
+каталог в том виде как он выглядел в какой-то момент в прошлом.
+
+Системы контроля версий дают пользователям возможность сохранять изменения на
+ветке "фиксируя **ревизию**". Созданная ревизия фактически является сводкой
+изменений, которые были сделаны с последнего момента когда дерево было
+сохранено.
+
+Эти ревизии имеют также и другое назначение. Например, можно комментировать
+ревизии, записав, что значит данный набор изменений, через необязательную
+запись в журнале. Реальные записи в журнале могут быть похожи на "Исправлен
+Web-шаблон для закрытия таблицы" и "Добавлена поддержка SFTP. Исправлен #595"
+
+Мы храним этот журнал, что бы позже, в случае каких-либо проблем с SFTP, можно
+было определить когда могла произойти проблема.
+
+Чем отличаются распределенные системы
+-------------------------------------
+
+Многие системы контроля версий хранят данные на серверах. Если кто-то хочет
+работать с кодом, который хранится в системе тогда ему нужно установить
+соединение с сервером и "создать рабочую копию" кода. При этом создается
+каталог в котором можно менять файлы и затем фиксировать изменения. Клиент
+системы затем соединяется с сервером системы и сохраняет изменения. Этот метод
+известен как централизованная модель.
+
+Централизованная модель может иметь некоторые недостатки. Централизованная
+система требует наличия соединения с сервером для любых действий по контролю
+версий. Это может быть проблематичным если сервер находится на другой машине в
+интернете, а клиент - нет. Или, хуже, клиент **в** интернете, а сервер - нет.
+
+Распределенные системы контроля версий обходят эту проблему сохраняя ветки на
+той же машине на которой находится клиент. В случае с Bazaar, ветка находится в
+том же самом месте, что и код хранящийся под контролем версий. Это позволяет
+пользователю сохранять (**фиксировать**) изменения когда он захочет -- даже без
+сетевого подключения. Пользователю нужен доступ к интернету только когда он
+хочет получить доступ к чьей-либо ветке в другом месте.
+
+Общее требование, что многие люди хотят отслеживать изменения для каталога,
+такие как изменения файлов и изменения в подкаталогах. Отслеживать это
+"руками" ужасный процесс, который со временем становится громоздким. До тех пор
+пока вы не попробуете систему контроля версий, такую как Bazaar. Такие
+инструменты автоматизируют процесс сохранения данных, создавая **ревизии**
+дерева каталога когда пользователь запрашивает сделать это.
+
+Системы контроля версий, такие как Bazaar, могут делать намного больше чем
+просто хранить изменения и отменять ошибочные действия. Например, с помощью
+Bazaar разработчики могут взять изменения кода на одной ветке и объединить их
+со связанной веткой -- даже если эти изменения хранятся на ветке которую создал
+кто-то другой. Это позволяет разработчикам сотрудничать без необходимости
+открывать доступ на запись к репозиторию.
+
+Bazaar помнит ''предков'' ревизии: предыдущие ревизии на которых основана
+текущая ревизия. Одна ревизия может иметь больше одного прямого потомка, каждый
+из которых со своими изменениями, что представляет дивергенцию в эволюции
+дерева. Создание веток в Bazaar позволяет нескольким людям сотрудничать в
+эволюции проекта, без необходимости работать жестко по шагам. Создание веток
+может быть полезным даже для одного разработчика.
+
+Представляемся Bazaar
+=====================
+
+Bazaar устанавливает единственную новую команду, **bzr**. Все возможности
+предоставляются через под-команды этой команды. Вы можете просмотреть краткую
+справку командой ``bzr help``. Некоторые идеи группируются по темам,
+используйте ``bzr help topics`` для списка доступных тем.
+
+Одна из функций системы контроля версий -- отслеживать кто сделал изменения. В
+распределенных системах для этого требуется идентифицировать каждого автора
+уникально в глобальном плане. Большинство людей уже имеют такой идентификатор:
+email адрес. Bazaar достаточно умен, что бы автоматически создавать email адрес
+из текущего имени и адреса хоста. Если вам не нравится предположение которое
+делает Bazaar вы сможете выбрать из трех опций:
+
+ #. Установить email адрес через ``bzr whoami``. Это наиболее простой путь.
+
+ Что бы установить такой глобальный идентификатор, используйте::
+
+ % bzr whoami "Ваше Имя <email@example.com>"
+
+ Если вы хотите использовать разные адреса для разных веток, то зайдите
+ в каталог с веткой и используйте::
+
+ % bzr whoami --branch "Ваше Имя <email@example.com>"
+
+ #. Установить email адрес в ``~/.bazaar/bazaar.conf`` [1]_, добавив следующие
+ строчки. Заметьте, что ``[DEFAULT]`` зависит от регистра символов::
+
+ [DEFAULT]
+ email=Ваше Имя <email@isp.com>
+
+ Как и выше вы можете переопределить эти установки для каждой ветки
+ создав секцию для ветки в ``~/.bazaar/locations.conf`` и добавив
+ следующие строчки::
+
+ [/путь/к/ветке]
+ email=Ваше Имя <email@isp.com>
+
+ #. Переопределить два предыдущих способа, установив ваш полный email адрес в
+ глобальную переменную среды ``$BZR_EMAIL``, или ``$EMAIL`` (``$BZR_EMAIL``
+ имеет больший приоритет).
+
+.. [1] Для Windows пользовательские файлы конфигурации могут быть найдены в
+ каталоге с данными приложений. Таким образом вместо
+ ``~/.bazaar/branch.conf`` конфигурация может быть найдена в:
+ ``C:\Documents and Settings\<пользователь>\Application Data\Bazaar\2.0\branch.conf``. Там же могут
+ быть найдены ``locations.conf``, ``ignore`` и каталог ``plugins``.
+
+Создаем ветку
+=============
+
+История по-умолчанию хранится на ветке в каталоге .bzr. В будущих версиях
+Bazaar будут средства для хранения истории в отдельном репозитории, который
+также сможет быть удаленным.
+
+Мы создаем новую ветку выполнив ``bzr init`` в уже созданном каталоге::
+
+ % mkdir tutorial
+ % cd tutorial
+ % ls -a
+ ./ ../
+ % pwd
+ /home/mbp/work/bzr.test/tutorial
+ %
+ % bzr init
+ % ls -aF
+ ./ ../ .bzr/
+ %
+
+Как и в CVS здесь три класса файлов: неизвестные, игнорируемые и под контролем
+версий. Команда **add** ставит файл под контроль версий, т.е. изменения в нем
+будут записываться системой::
+
+ % echo 'hello world' > hello.txt
+ % bzr status
+ unknown:
+ hello.txt
+ % bzr add hello.txt
+ added hello.txt
+ % bzr status
+ added:
+ hello.txt
+
+Если вы добавили не тот файл просто сделайте ``bzr remove``, что бы сделать его
+опять неизвестным. Рабочая копия файла не будет удалена в этом случае, хотя она
+может быть удалена в других случаях [2]_.
+
+.. [2] ``bzr remove`` удалит рабочую копию если она находится под контролем
+ версий, но не имеет изменений с последней зафиксированной версии. Вы
+ можете оставить файл указав опцию ``--keep`` для ``bzr remove``, или
+ удалить с опцией ``--force``.
+
+Размещение веток
+================
+
+Вся история хранится на ветке, которая является всего лишь каталогом на диске
+содержащим файлы управления. По-умолчанию здесь нет отдельного репозитория, или
+базы данных как в svn, или svk. По желанию вы можете создать репозиторий (см.
+команду ``bzr init-repo``). Это можно сделать в случае очень больших веток, или
+большого количества веток для проекта среднего размера.
+
+Мы обычно обращаемся к веткам на нашем компьютере просто передав имя каталога
+содержащего ветку. bzr также поддерживает доступ к веткам через HTTP и SFTP,
+например::
+
+ % bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+ % bzr log sftp://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
+
+Установив для bzr плагины можно также осуществлять доступ к веткам с
+использованием rsync.
+
+Смотрите секцию `Публикация ветки`_ что бы получить больше информации о том как
+поместить свою ветку в нужное место.
+
+Просмотр изменений
+==================
+
+Как только вы закончили свою работу, вы захотите **зафиксировать** ее в истории
+ревизий. Хорошая практика фиксировать изменения достаточно часто: когда
+заработала новая функциональность, исправлена ошибка, или улучшен код, или
+документация. При этом стоит проверить, что код компилируется и проходит все
+тесты перед фиксацией, что бы быть уверенным, что каждая ревизия в хорошем
+состоянии. Также можно просмотреть свои изменения, для уверенности, что вы
+фиксируете именно то, что хотели и получить шанс проверить свою работу перед
+тем как записать ее постоянно.
+
+Две команды bzr особенно полезны здесь: **status** и **diff**.
+
+bzr status
+----------
+
+Команда **status** показывает какие изменения были сделаны в рабочем каталоге
+с момента последней ревизии::
+
+ % bzr status
+ modified:
+ foo
+
+``bzr status`` скрывает "неинтересные" файлы которые, либо не менялись, либо
+игнорируются. Также команде status могут быть переданы необязательные имена
+файлов, или каталогов для проверки.
+
+bzr diff
+--------
+
+Команда **diff** показывает изменения в тексте файлов в стандартном формате
+diff. Вывод этой команды может быть передан другим командам, таким как
+''patch'', ''diffstat'', ''filterdiff'' и ''colordiff''::
+
+ % bzr diff
+ === added file 'hello.txt'
+ --- hello.txt 1970-01-01 00:00:00 +0000
+ +++ hello.txt 2005-10-18 14:23:29 +0000
+ @@ -0,0 +1,1 @@
+ +hello world
+
+С опцией ``-r`` дерево файлов сравнивается с ранней ревизией, или показываются
+изменения между двумя ревизиями::
+
+ % bzr diff -r 1000.. # изменения начиная с r1000
+ % bzr diff -r 1000..1100 # изменения c 1000 до 1100
+
+Опция ``--diff-options`` говорит bzr запустить внешнюю программу diff, передав
+ей опции. Например::
+
+ % bzr diff --diff-options --side-by-side foo
+
+Некоторые проекты предпочитают показывать префиксы в начале текста изменений
+для старых (old) и новых (new) файлов. Опция ``--prefix`` может быть
+использована для установки такого префикса. Плюс к этому команда ``bzr diff
+-p1`` выводит префиксы в форме которая подходит для команды ``patch -p1``.
+
+Фиксация изменений
+==================
+
+Когда состояние рабочего дерева подходит для сохранения оно может быть
+**зафиксировано** на ветке, что создаст новую ревизию содержащую снимок
+состояния дерева.
+
+bzr commit
+----------
+
+Команде **commit** можно передать сообщение описывающее изменения в ревизии.
+Она также записывает идентификатор пользователя, текущее время и временную
+зону, плюс список измененных файлов и их содержимого. Сообщение описывающее
+изменения определяется через опцию ``-m``, или ``--message``. Можно также
+вводить сообщения состоящие из нескольких строк; в большинстве оболочек вы
+можете сделать это оставив открытую кавычку в конце строки.
+
+::
+
+ % bzr commit -m "добавлен первый файл"
+
+Также можно использовать опцию ``-F``, для получения сообщения из файла.
+Некоторые люди делают заметки изменений во время работы над ними, а затем
+просматривают изменения, что бы быть уверенными, что они сделали то, что хотели
+сделать. (Этот файл может быть также полезен когда вы возвращаетесь к своей
+работе после перерыва.)
+
+Сообщение из текстового редактора
+=================================
+
+Если вы не используете опции ``-m`` и ``-F`` тогда bzr откроет текстовый
+редактор для ввода сообщения. Какой редактор запускать может быть настроено
+через переменные среды ``$VISUAL``, или ``$EDITOR``, которые могут быть
+переопределены опцией ``editor`` в файле ``~/.bazaar/bazaar.conf``; опция
+``$BZR_EDITOR`` переопределяет все описанные выше настройки. Если вы выходите
+из редактора без каких-либо изменений, то фиксация будет прервана.
+
+Файл который открывается в редакторе содержит горизонтальную линию. Часть файла
+ниже этой линии включена только для информации и не будет частью сообщения об
+изменениях. Ниже линии показывается список файлов которые были изменены. Для
+создания сообщения вам надо написать свое сообщение выше линии, сохранить его и
+выйти из редактора.
+
+Если вы хотите увидеть изменения содержимого файлов которые будут
+зафиксированы, при редактировании сообщения вам нужно указать опцию
+``--show-diff`` для команды ``commit``. Эта опция добавит изменения в файл
+который будет открыт в редакторе ниже линии и списка измененных файлов. Это
+значит, что вы можете читать изменения при редактировании сообщения, но они не
+будут включены в сообщение когда вы закончите редактировать. Если вы хотите,
+что бы части изменений были включены в сообщение вы можете скопировать и
+вставить их выше ограничительной линии.
+
+Выборочная фиксация
+-------------------
+
+Если вы передадите список имен файлов, или каталогов после команды commit, то
+будут зафиксированы только изменения для переданных объектов. Например::
+
+ % bzr commit -m "исправления документации" commit.py
+
+По умолчанию bzr всегда фиксирует все изменения для дерева, даже если запущен
+из подкаталога. Что бы зафиксировать только изменения от текущего каталога
+и ниже, используйте::
+
+ % bzr commit .
+
+
+Удаление не зафиксированных изменений
+=====================================
+
+Если вы сделали какие-либо изменения и не хотите оставлять их, используйте
+команду **revert**, что бы вернутся к состоянию предыдущей ревизии. Хорошая
+идея, использовать сначала ``bzr diff`` для просмотра изменений. По умолчанию
+команда revert отменяет изменения на всем дереве, но если ей переданы имена
+файлов, или каталогов то будут затронуты только они. ``bzr revert`` также
+очищает список ревизий ожидающих объединения.
+
+Игнорирование файлов
+====================
+
+Многие деревья с исходным кодом содержат файлы которые не нужно хранить под
+контролем версий, например резервные файлы текстового редактора, объектные
+файлы и собранные программы. Вы можете просто не добавлять их, но они всегда
+будут обнаруживаться как неизвестные. Вы также можете сказать bzr игнорировать
+их добавив их в файл ``.bzrignore`` в корне рабочего дерева.
+
+Этот файл содержит список шаблонов файлов, по одному в каждой строчке. Обычное
+содержимое может быть таким::
+
+ *.o
+ *~
+ *.tmp
+ *.py[co]
+
+Если шаблон содержит слеш, то он будет сопоставлен с полным путем начиная от
+корня рабочего дерева; иначе он сопоставляется только с именем файла. Таким
+образом пример выше игнорирует файлы с расширением ``.o`` во всех
+подкаталогах, но пример ниже игнорирует только ``config.h`` в корне рабочего
+дерева и HTML файлы в каталоге ``doc/``::
+
+ ./config.h
+ doc/*.html
+
+Для получения списка файлов которые игнорируются и соответствующих им шаблонов
+используйте команду ``bzr ignored``::
+
+ % bzr ignored
+ config.h ./config.h
+ configure.in~ *~
+
+Нет проблем если шаблон для игнорирования подходит для файла под контролем
+версий, или вы добавили файл который игнорируется. Шаблоны не имеют никакого
+эффекта на файлы под контролем версий, они только определяют показываются
+неизвестные файлы, или просто игнорируются.
+
+Файл ``.bzrignore`` обычно должен быть под контролем версий, что бы новые копии
+ветки видели такие же шаблоны::
+
+ % bzr add .bzrignore
+ % bzr commit -m "Добавлены шаблоны для игнорирования"
+
+
+Глобальные шаблоны для игнорирования
+------------------------------------
+
+Обычно есть файлы которые нужно игнорировать и они не специфичны для отдельных
+проектов, а скорее специфичны для пользователя. Например, временные файлы
+текстового редактора, или персональные временные файлы. Вместо того, что бы
+добавлять их для игнорирования в каждом проекте, bzr поддерживает глобальный
+файл игнорирования ``~/.bazaar/ignore`` [1]_. Он имеет такой же синтаксис, что
+и файл игнорирования для каждого проекта.
+
+
+Просмотр истории
+================
+
+bzr log
+-------
+
+Команда ``bzr log`` показывает список предыдущих ревизий. Команда ``bzr log
+--forward`` делает тоже самое, но в хронологическом порядке, показывая более
+поздние ревизии в конце.
+
+Как и ``bzr diff``, ``bzr log`` поддерживает опцию ``-r``::
+
+ % bzr log -r 1000.. # Ревизия 1000 и все после нее
+ % bzr log -r ..1000 # Все до и включая r1000
+ % bzr log -r 1000..1100 # изменения с 1000 до 1100
+ % bzr log -r 1000 # Изменения только для ревизии 1000
+
+
+Статистика ветки
+================
+
+Команда ``bzr info`` показывает суммарную информацию о рабочем дереве и истории
+на ветке.
+
+
+Каталоги под контролем версий
+=============================
+
+bzr может контролировать файлы и каталоги, отслеживая переименования и
+упрощая их последующее объединение::
+
+ % mkdir src
+ % echo 'int main() {}' > src/simple.c
+ % bzr add src
+ added src
+ added src/simple.c
+ % bzr status
+ added:
+ src/
+ src/simple.c
+
+
+Удаление файлов
+===============
+
+Вы можете удалить файл, или каталог из под контроля версий просто удалив их
+из рабочего каталога. Это немного отличается от CVS, которая требует что бы вы
+также сделали ``cvs remove``.
+
+``bzr remove`` удаляет файл из под контроля версий, но может и не удалять
+рабочую копию файла [2]_. Это удобно когда вы добавили не тот файл, или решили,
+что файл на самом деле не должен быть под контролем версий.
+
+::
+
+ % rm -r src
+ % bzr remove -v hello.txt
+ ? hello.txt
+ % bzr status
+ removed:
+ hello.txt
+ src/
+ src/simple.c
+ unknown:
+ hello.txt
+
+Если вы вдруг удалили не тот файл, то вы можете использовать ``bzr revert`` что
+бы восстановить его.
+
+
+Ветвление
+=========
+
+Часто вместо того что бы начинать свой собственный проект, вы хотите предложить
+изменения для уже готового проекта. Что бы сделать это вам нужно получить копию
+готовой ветки. Так как эта копия может быть потенциальной новой веткой эта
+команда называется **branch**::
+
+ % bzr branch lp:bzr bzr.dev
+ % cd bzr.dev
+
+Эта команда копирует полную историю ветки и после этого вы можете делать все
+операции с ней локально: просматривать журнал, создавать и объединять другие
+ветки. Здесь также есть опция для получения только части истории если это
+необходимо.
+
+Копию другой ветки можно также получить просто скопировав ее каталог,
+развернув архив, или скопировав удаленно через такую утилиту как rsync.
+
+
+Следование за изменениями основного проекта
+===========================================
+
+Вы можете обновлять свою ветку из родительской через получение ее изменений::
+
+ % bzr pull
+
+После этого локальный каталог будет копией родительского. Это включает и
+''историю ревизий'' - список изменений сделанных на родительской ветке, а не
+объединенных с других веток.
+
+Эта команда работает только если локальная ветка, либо более старая копия
+родительской ветки без новых фиксаций, либо все последние фиксации уже были
+объединены с родительской веткой.
+
+Объединение со связанных веток
+==============================
+
+Если две ветки разошлись (обе имеют уникальные изменения) тогда ``bzr merge`` -
+это подходящая команда для использования. Объединение автоматически вычислит
+изменения которые существуют на объединяемой ветке и отсутствуют в локальной
+ветке и попытается объединить их с локальной веткой.
+
+::
+
+ % bzr merge URL
+
+В случае конфликта при объединении будут созданы три файла с одними именем, но
+разными расширениями. Файл с общими изменениями будет с расширением ".BASE",
+файл с локальными изменениями будет с расширением ".THIS" и файл с изменениями
+из объединяемой ветки будет с расширением ".OTHER". Используя такую программу
+как kdiff3 вы теперь сможете достаточно легко объединить их в один файл. Для
+фиксации изменений вам нужно переименовать объединенный файл (".THIS") в файл с
+оригинальным именем. И для завершения исправления конфликта нужно использовать
+команду resolve, которая удалит файлы ".OTHER" и ".BASE". Команда commit будет
+выдавать ошибку пока существует один из файлов с расширением .BASE, .THIS, или
+.OTHER.
+
+::
+
+ % kdiff3 file.BASE file.OTHER file.THIS
+ % mv file.THIS file
+ % bzr resolve file
+
+[**TODO**: описать маркеры конфликтов внутри файлов]
+
+
+Публикация ветки
+================
+
+Для публикации ветки bzr вам не нужен специализированный сервер, нужен просто
+обычный Web-сервер. Просто перенесите файлы на ваш сервер, включая каталог
+.bzr. Можно опубликовать ветку (или изменения на ветке) одним из следующих трех
+способов:
+
+* Лучший способ - использовать для этого сам bzr.
+
+ ::
+
+ % bzr push sftp://servername.com/path/to/directory
+
+ (Каталог назначения должна быть создан заранее, если только не указана
+ опция ``--create-prefix``)
+
+* Другой способ - плагин ``rspush`` который включен в BzrTools и использует
+ rsync для публикации изменений в истории ревизий и рабочем дереве.
+
+* Вы также можете скопировать файлы руками, переслав архив, или используя
+ rsync, или другой метод пересылки. Обычно это менее безопасно чем
+ использовать команду ``push``, но может быть быстрее и проще в каких-то
+ ситуациях.
+
+Перемещение изменений между деревьями
+=====================================
+
+Это случается и с лучшими из нас: в какой-то момент вы делаете изменения не в
+том дереве файлов. Возможно потому, что вы случайно начали работать не в том
+каталоге, либо изменений оказались больше чем вы ожидали и вы решили создать
+для них новую ветку.
+
+Для перемещения изменений из одного дерева в другое используйте
+
+::
+
+ % cd NEWDIR
+ % bzr merge --uncommitted OLDDIR
+
+Эта команда перенесет все не зафиксированные изменения с ветки OLDDIR на ветку
+NEWDIR. Команда не будет переносить зафиксированные изменения, даже если они
+могли бы быть объединены с NEWDIR обычным объединением. Изменения также
+остаются и в OLDDIR, но вы можете использовать ``bzr revert OLDDIR`` для их
+удаления, как-то только убедитесь, что с NEWDIR все нормально.
+
+NEWDIR не обязательно должен быть копией OLDDIR, но они должны быть связанными
+ветками. Чем больше они отличаются, тем больше шанс возникновения конфликтов.
diff --git a/doc/ru/tutorials/using_bazaar_with_launchpad.txt b/doc/ru/tutorials/using_bazaar_with_launchpad.txt
new file mode 100644
index 0000000..e9fa4cf
--- /dev/null
+++ b/doc/ru/tutorials/using_bazaar_with_launchpad.txt
@@ -0,0 +1,461 @@
+================================
+Использование Bazaar с Launchpad
+================================
+
+.. contents::
+ Содержание
+.. sectnum::
+
+Мотивация
+=========
+
+Сообщества отличаются от команд
+-------------------------------
+
+Количество человек в команде, необходимой для создания первой версии
+какого-либо программного обеспечения, может различаться в разы - от одного
+человека до нескольких тысяч. В зависимости от требований, сложность задач, как
+технических, так и управленческих, может быть просто огромна. Как описано в
+Руководстве пользователя Bazaar, выбор "правильных" процессов и использование
+таких инструментов как Bazaar, может существенно помочь в поддержке
+соответствующих рабочих циклов.
+
+Но успех программного обеспечения требует больше чем просто хорошую команду -
+здесь требуется здоровое и активное *сообщество*. Обычно эта группа намного
+больше команды, поскольку включает всех заинтересованных в данном программном
+обеспечении: команду разработки, пользователей, партнеров по подготовке
+кадров, партнеров по поддержке, сторонних разработчиков и так далее.
+
+Хорошие сообщества хорошо известны в мире открытого исходного кода. Но их
+полезность намного выше этого: большинство успешных поставщиков коммерческого
+программного обеспечения достаточно опытны в создании и управлении
+сообществами, которые растут вокруг их флагманских продуктов.
+
+Как и хорошие команды, хорошие сообщества не появляются просто так. Правильная
+политика и руководящие принципы имеют основополагающее значение при развитии
+правильного поведения и здорового отношения между участниками. Для более
+подробного понимания этой темы можно обратится к основополагающей книге Карла
+Фогеля (Karl Fogel): `Создание программного обеспечения с открытым кодом
+(Producing Open Source Software) <http://www.producingoss.com/>`_.
+
+
+Потребность в совместных средах разработки
+------------------------------------------
+
+Развитый набор инструментов также важен для отслеживания и управления
+информацией и рабочими процессами в сообществе. Такие инструменты называются
+совместными средами разработки (Collaborative Development Environments
+(CDEs)). Обычно эти инструменты работают на базе Web'а и управляют такими
+вещами как анонсы, задачи и ошибки, вопросы и ответы, ресурсы для скачивания,
+документы и исходный код. Вот несколько примеров совместных сред разработки:
+`Launchpad <https://launchpad.net>`_,
+`SourceForge <http://sourceforge.net>`_,
+`java.net <http://java.net>`_ и
+`SAP Community Network <https://www.sdn.sap.com/irj/sdn>`_.
+
+
+Помощь сообществам в работе с зависимыми от них сообществами
+------------------------------------------------------------
+
+Многие успешные продукты имеют большое число зависящих от них проектов.
+Другими словами, с успехом проекта появляется новая задача: общение с другими
+сообществами и понимание того как ваши изменения скажутся на них. Это наиболее
+очевидно для таких проектов как:
+
+* языков программирования, например, Python, PHP, Ruby, Java, Perl и др.
+* компиляторов, например, gcc, JDK и др.
+* библиотек, например, zlib, openssl и др.
+* каркасов, например, Zope, Ruby on Rails, Spring и др.
+
+В равной степени это относится и к популярным приложениям для которых могут
+создаваться дополнения, например, Firefox, Thunderbird, OpenOffice.org,
+Drupal, Wordpress, Joomla и др.
+
+Здесь необходимы инструменты, которые помогают сообществам работать вместе над
+отслеживанием и управлением задачами и исправлениями между сообществами. Такие
+инструменты помогают людям по обе стороны:
+
+* пользователи могут сообщить о проблемах своими словами, например, построение
+ изображения типа X не работает в приложении Y под операционной системой Z.
+
+* разработчики могут лучше оценить реакцию на сделанное изменение или
+ исправление, например, сделает ли исправление этой ошибки в графической
+ библиотеки счастливее пользователей этих 5-и приложений под этими 10-ю
+ операционными системами.
+
+Посредники играют важную роль *соединяя точки* и создавая коммуникацию между
+верхней и нижней точками линии. Во многих случаях, они могут так же исправить
+проблему для конечного пользователя, выпустив заплатку и передав рекомендуемое
+исправление основной команде разработчиков. Отслеживание всего этого в течении
+продолжительного времени - задача не из легких.
+
+Launchpad: Больше разработки, меньше трений
+-------------------------------------------
+
+Кроме спонсорства разработки `Ubuntu <http://www.ubuntu.com>`_ и `Bazaar
+<http://bazaar.canonical.com>`_, Canonical так же предоставляет Launchpad,
+https://launchpad.net, как бесплатный сервис для сообществ с открытым исходным
+кодом. Launchpad является одной из самых интересных сред совместной разработки
+по следующим причинам:
+
+* он создает связь между многими отслеживаемыми сущностями, например, ветки
+ исходного кода могут быть связаны с исправлением ошибок
+
+* кроме управления накопленными знаниями, также предоставляется планирование и
+ поддержка будущего разработки через такие возможности как отслеживание
+ направления развития, контрольные точки и планы развития
+
+* предоставляются инструменты для перевода и сборки пакетов, что снижает
+ барьер для переводчиков и тестеров пожелавших присоединиться к вашему
+ сообществу с помощью
+
+* служит связующим звеном между различными сообществами для совместной работы
+ над связанными задачами и направлениями развития.
+
+Иными словами, Launchpad был разработан чтобы помочь росту вашего сообщества и
+снизить трения при работе как *внутри* сообщества, так и *между* сообществами.
+В конечном счете, это означает, что тратится меньше времени на рутинные задачи
+и больше на интересные разработки.
+
+
+Bazaar: клиент системы контроля версий для Launchpad
+----------------------------------------------------
+
+Это руководство рассматривает как Bazaar и Launchpad могут быть использованы
+вместе и дополнять друг друга. Важно помнить о том, что:
+
+1. Bazaar можно использовать без Launchpad
+2. Launchpad можно использовать без Bazaar.
+
+И все же, по замыслу, их сумма больше чем каждый из инструментов по
+отдельности.
+
+
+Поиск и просмотр веток с помощью Launchpad
+==========================================
+
+Поиск доступных веток
+---------------------
+
+Хотя использование распределённой системы контроля версий даёт много
+преимуществ, в то же время исчезает всезнающий центральный сервер, который
+знает обо всех доступных ветках. Действительно, в распределённой среде
+интересующие ветки могут буквально существовать в сотнях мест во всему
+Интернету (или внутри Интранета).
+
+Launchpad заполняет этот пробел, предоставляя реестр веток.
+
+
+Регистрация веток
+-----------------
+
+Ветки могут быть загружены на Launchpad или просто зарегистрированы как
+доступные из внешних источников. Веткам так же можно назначать статусы, такие
+как *Новая*, *В разработке*, *Готовая* или *Отмененная*.
+
+Заметка: Внешние ветки могут даже располагаться в старых системах контроля
+версий, таких как CVS и Subversion. Код из этих систем будет периодически
+сканироваться и преобразовываться в ветки Bazaar. Конечно же, для максимальной
+точности, предпочтительнее чтобы внешние ветки были в формате Bazaar.
+
+
+Просмотр веток
+--------------
+
+Для веток можно просматривать их список, фильтровать и сортировать по
+множеству атрибутов, включая Имя, Регистратора, Автора, Состояние, Возраст и
+время последней фиксации. Также работает просмотр веток, что легко позволяет
+увидеть следующее:
+
+* откуда можно скачать ветку
+* как залить изменения
+* недавние фиксации и изменения, сделанные каждым разработчиком
+* исходный код отдельных файлов для указанной ревизии.
+
+
+Доступ к коду в Launchpad с помощью Bazaar
+==========================================
+
+Получение кода для проекта с открытым исходным кодом
+----------------------------------------------------
+
+Launchpad отслеживает тысячи проектов с открытым исходным кодом и вне
+зависимости от того хранится этот код в Bazaar, CVS или Subversion
+пользователи Bazaar легко могут получить этот код так::
+
+ bzr branch lp:имя-проекта
+
+где `имя-проекта` - это идентификатор проекта на Launchpad. Вот некоторые
+примеры::
+
+ bzr branch lp:inkscape
+ bzr branch lp:amarok
+ bzr branch lp:python
+ bzr branch lp:rails
+ bzr branch lp:java-gnome
+
+После этого вы можете просматривать код локально с помощью вашего любимого
+редактора или среды разработки и при желании изменять его.
+
+Если для проекта зарегистрировано несколько выпусков (например, выпуск
+разработки в выпуск поддержки), тогда свежий код для заданного выпуска можно
+получить используя команду::
+
+ bzr branch lp:имя-проекта/выпуск
+
+Публикация ваших изменений
+--------------------------
+
+Исправив эту надоедливую ошибку или добавив новую крутую возможность, о
+которой вы давно мечтали, пришло время удивить ваших друзей и сделать мир
+лучше, сделав ваш код доступным для других. Как уже объяснялось раньше,
+Launchpad это бесплатная служба для размещения веток Bazaar и поэтому вы
+можете опубликовать свою ветку на нём, так чтобы другие смогли получить доступ
+к вашему коду. Например, предположим что вы уже участник соответствующей
+команды, авторизуйтесь на Launchpad таким образом::
+
+ bzr launchpad-login пользователь
+
+где `пользователь` - это ваш идентификатор пользователя Launchpad. После этого
+вы можете залить ваши изменения на ветку команды вот так::
+
+ bzr push lp:~имя-команды/имя-проекта/имя-ветки
+
+Теперь другие могут скачать ваш код таким образом::
+
+ bzr branch lp:~имя-команды/имя-проекта/имя-ветки
+
+
+Личные ветки
+------------
+
+Даже если вы не член какой-либо команды Launchpad можно использовать для
+публикации ваших изменений. В этом случае просто создайте личную ветку::
+
+ bzr push lp:~пользователь/имя-проекта/имя-ветки
+
+Другие затем могут скачать ваш код таким образом::
+
+ bzr branch lp:~пользователь/имя-проекта/имя-ветки
+
+Заметка: даже в случае публикации личной ветки будет вежливо уведомить
+основных разработчиков о вашей ветке, чтобы они смогли взять ваши изменения,
+если они подходят и для других пользователей и соответствуют стандартам
+качества проекта.
+
+
+Связывание веток в Launchpad
+============================
+
+Привязка ветки к сообщению об ошибке
+------------------------------------
+
+После регистрации ветки вы можете связать её с ошибкой, чтобы заинтересованные
+в ее исправлении люди могли отслеживать изменения и скачать исправление, когда
+оно станет доступно.
+
+Чтобы сделать это выполните следующие шаги:
+
+1. Перейдите к странице с нужной ошибкой.
+
+2. Выберите `Add branch` (Добавить ветку) в разделе `Actions` (Действия).
+
+3. Выберите ветку.
+
+4. При желании вы можете изменить состояние (State) связи. По умолчанию
+ состояние будет *Fix In Progress* (Работа над исправлением), но вы можете
+ установить другое состояние, например *Fix Available* (Исправление
+ доступно), если ветка уже содержит исправление.
+
+При желании вы также можете добавить произвольный комментарий о связи между
+ошибкой и веткой.
+
+
+Изменение состояния ветки в Launchpad во время фиксации в Bazaar
+----------------------------------------------------------------
+
+Bazaar и Launchpad способны работать вместе, чтобы уменьшить ваши заботы по
+управлению состоянием ветки. Когда вы выполняете фиксацию с помощью Bazaar,
+используйте параметр --fixes::
+
+ bzr commit --fixes lp:1234 -m "..."
+
+где 1234 |--| это идентификатор ошибки. Эти данные изменят State (состояние
+отношения ветки к ошибке) на *Fix Available* (Исправление доступно). Если одна
+единственная фиксация исправляет несколько ошибок, то параметр --fixes может
+быть указан несколько раз.
+
+Самое интересное здесь заключается в том, что вам не обязательно иметь доступ
+к Launchpad в момент фиксации. При использовании ``--fixes`` идентификатор
+ошибки сохраняется в виде специальных метаданных, которые Launchpad увидит при
+очередной публикации ваших изменений или когда ваша публичная ветка будет
+просканирована в очередной раз.
+
+Заметка: Launchpad не будет закрывать сообщение об ошибке только потому, что
+существует ветка с исправлением. Для этого есть несколько причин. Во-первых,
+обычно исправления из вашей ветки должны быть объединены с главной веткой
+разработки, иначе большинство команд не будет считать ошибку исправленной.
+Во-вторых, многие команды придерживаются отдельного процесса для подтверждения
+исправлений ошибок, в добавление к утверждению разработчика об этом.
+
+Как поясняется далее, функция отслеживания объединений веток на Launchpad в
+настоящее время находится в стадии разработки. Как только эта функция будет
+готова более подходящим поведением станет автоматическое изменение состояния
+ошибки на *Fix Committed* (исправление зафиксировано).
+
+
+Связь ветки с планом
+--------------------
+
+После регистрации ветки вы можете связать её с планом, чтобы люди,
+заинтересованные в этом плане могли отслеживать и тестировать новые
+возможности по мере разработки.
+
+Чтобы это сделать, выполните следующие шаги:
+
+1. Перейдите к нужному плану (Blueprint).
+
+2. Выберите `Link branch` (Связать ветку) в разделе `Actions` (Действия).
+
+3. Выберите ветку.
+
+При желании вы также можете добавить произвольный комментарий об отношении
+ветки к плану.
+
+
+Управление релизами с помощью Launchpad
+=======================================
+
+Интеграция изменений
+--------------------
+
+Когда разработка на ветке закончена и она опубликована, сообщества обычно
+проходят через строгий процесс, прежде чем изменения будут интегрированы в
+основной продукт и предоставлены конечным пользователям. Вот некоторые из
+возможных шагов:
+
+* просмотр изменений другими участниками проекта
+
+* принятие решения, в какой релиз будут включены изменения, например, в
+ следующий релиз с исправлениями, или в следующее крупное обновление, или в
+ оба
+
+* прогон функциональных тестов для выявления ошибок
+
+* измерение производительности
+
+* включение в предварительные версии для тестирования конечными пользователями
+
+* обновление документации, например, заметок о выпуске
+
+* перевод пользовательского интерфейса и документации на разные языки.
+
+Этот раздел дает обзор возможностей Launchpad, которые помогают получить
+высокое качество кода в конечном продукте. Хорошая интеграция с Bazaar
+является основой для того, чтобы это прошло гладко.
+
+Примечание: в тех случаях, когда указано, некоторые из следующих возможностей
+всё ещё находятся в стадии разработки. Если одна или несколько таких
+возможностей вам интересны, рассмотрите возможность вступления в команду
+бета-тестирования Launchpad по следующей ссылке:
+https://help.launchpad.net/JoiningLaunchpadBetaTesters. В этом случае, вы
+сможете получить предварительный доступ к возможностям и сможете дать отзыв
+разработчиками до широкого внедрения.
+
+
+Предложение по объединению веток
+--------------------------------
+
+После перехода к ветке в Launchpad, одно из доступных действий - *Propose for
+merging* (Предложить объединение). Это действие позволяет вам указать, с какой
+веткой этот код мог бы быть объединен.
+
+Отслеживание знаний о том, какие ветки предлагается объединить в главную,
+помогает менеджерам выпусков держать на виду то, что ещё должно быть
+завершено, либо может быть завершено, до даты выпуска. Используя эту
+информацию, они могут убедиться, что ветки объединены после завершения их
+необходимых обзоров. В простом случае, менеджер выпуска может объединить ветки
+вручную. В более сложных ситуациях, объединение может быть сделано роботом
+(таким, как `PQM`_) автоматически, когда ветки перейдут в правильное состояние
+(например, *Review completed* (Обзор завершен)).
+
+.. _PQM: https://launchpad.net/pqm
+
+
+Отслеживание обзора кода
+------------------------
+
+Некоторые функции в Launchpad все еще в стадии разработки, например
+отслеживание состояний, обсуждений и результатов обзора кода. Ожидается, что
+эти функции будут интегрированы с предложениями по объединению веток и
+просмотром веток.
+
+
+Архивы личных пакетов (PPAs)
+----------------------------
+
+PPAs помогают разработчикам и командам разработки выдать определенный выпуск
+на руки пользователям для раннего тестирования и получения отзывов. Другими
+словами, PPA позволяет разработчику создать сообщество тестеров,
+заинтересованных в их изменениях. Тестирующее сообщество может установить
+пакеты, запускать их в течение тестового периода, а затем аккуратно удалить их
+из системы.
+
+Дальнейшую информацию можно найти по адресу
+https://help.launchpad.net/PPAQuickStart
+
+
+Переводы
+--------
+
+Модуль переводов в Launchpad сделан для того чтобы любой желающий мог легко
+присоединиться к переводу приложений на известные ему языки. Переводчики
+защищены от подробностей низкого уровня.
+
+Launchpad отслеживает переводы для каждой основной версии проекта по
+отдельности, что позволяет переводчикам продолжать совершенствовать перевод
+ваших стабильных релизов, пока другие могут начать работу над новыми версиями,
+которые все ещё находятся в разработке. Скорость перевода увеличивается из-за
+совместного использования ресурсов между проектами. Автоматические подсказки,
+из библиотеки в 750 тысяч переведенных строк, а также сообщество из
+19 тысяч зарегистрированных переводчиков может радикально сократить время,
+необходимое для локализации вашего проекта на многие языки.
+
+
+Итоги
+=====
+
+Сообщества к которым мы присоединяемся, будь то в реальной жизни, или онлайн,
+говорят многое о нас. Обратная сторона этого заключается в инструментах
+которые вы выбираете для сообщества - в частности, CDE и инструмент контроля
+версий. Это может иметь большое значение для тех кто пожелает присоединиться,
+и насколько легко они смогут помочь.
+
+Сами по себе, Launchpad и Bazaar являются очень полезными инструментами.
+Вместе они могут:
+
+* помочь вашему сообществу отслеживать основные ресурсы, такие как исходный
+ код и знания;
+* помочь ему расти, снизив вступительный барьер;
+* помочь ему во взаимодействии с зависимыми сообществами.
+
+В частности, Launchpad является сервисом хранения свободного кода для ваших
+веток Bazaar. Ветки можно просматривать онлайн, их можно связать с ошибками и
+планами. А их статус по отношению к ошибке может автоматически управляться
+упоминанием об ошибке при сохранении в Bazaar. Дальнейшая интеграция находится
+в стадии развития с целью оптимизации процесса от *большой идеи* до
+*работающего кода в руках конечных пользователей*.
+
+Если у вас есть отзывы или пожелания о том, как лучше интегрировать Bazaar и
+Launchpad, пожалуйста связывайтесь с нами через список рассылки
+bazaar@lists.canonical.com.
+
+Хотя Launchpad разработан как бесплатный сервис для поддержки проектов с
+открытыми исходными текстами, Canonical может сделать его доступным и для
+разработчиков коммерческого программного обеспечения, в зависимости от их
+требований. Мы с удовольствием выслушаем ваше мнение, если вы считаете, что
+Launchpad был бы полезен для управления вашим сообществом, будь оно открытое
+или нет.
+
+
+.. |--| unicode:: U+2014
diff --git a/doc/ru/user-guide/branching_a_project.txt b/doc/ru/user-guide/branching_a_project.txt
new file mode 100644
index 0000000..1d43659
--- /dev/null
+++ b/doc/ru/user-guide/branching_a_project.txt
@@ -0,0 +1,112 @@
+Branching a project
+===================
+
+Branch URLs
+-----------
+
+Before someone else can get a copy of your work, you need to
+agree on a transfer technology.
+You may decide to make the top level directory of your branch
+a network share, an approach familiar to Windows users.
+Linux and OS X users might prefer access to be
+via SFTP, a secure protocol built-in to most SSH servers.
+Bazaar is *very* flexible in this regard with support for
+lots of protocols some of which are given below.
+
+ =========== ======================================================
+ Prefix Description
+ =========== ======================================================
+ file:// Access using the standard filesystem (default)
+ sftp:// Access using SFTP (most SSH servers provide SFTP).
+ bzr:// Fast access using the Bazaar smart server.
+ ftp:// Access using passive FTP.
+ http:// Read-only access to branches exported by a web server.
+ =========== ======================================================
+
+As indicated above, branches are identified using URLs with the
+prefix indicating the transfer technology. If no prefix is given,
+normal filenames are assumed. For a complete list of supported
+protocols, see the ``urlspec`` online help topic or the
+`URL Identifiers <../user-reference/bzr_man.html#url-identifiers>`_
+section of the Bazaar User Reference.
+
+.. _a-reminder-about-shared-repositories:
+
+Напоминание о разделяемых репозиториях
+--------------------------------------
+
+Before getting a copy of a branch, have a quick think about
+where to put it on your filesystem. For maximum storage
+efficiency down the track, it is recommended that branches
+be created somewhere under a directory that has been set up
+as a shared repository. (See `Feature branches`_ in
+n `Organizing your workspace`_ for a commonly used layout.)
+For example::
+
+ bzr init-repo my-repo
+ cd my-repo
+
+You are now ready to grab a branch from someone else and
+hack away.
+
+The branch command
+------------------
+
+To get a branch based on an existing branch, use the ``branch`` command.
+The syntax is::
+
+ bzr branch URL [directory]
+
+If a directory is not given, one is created based on the last part of
+the URL. Here are some examples showing a drive qualified path (M:/) and an
+SFTP URL respectively::
+
+ bzr branch M:/cool-trunk
+ bzr branch sftp://bill@mary-laptop/cool-repo/cool-trunk
+
+This example shows explicitly giving the directory name to use for the
+new branch::
+
+ bzr branch /home/mary/cool-repo/cool-trunk cool
+
+Time and space considerations
+-----------------------------
+
+Depending on the size of the branch being transferred and the
+speed and latency of the network between your computer and the
+source branch, this initial transfer might take some time.
+Subsequent updates should be much faster as only the
+changes are transferred then.
+
+Keep in mind that Bazaar is transferring the
+complete history of the branch, not just the latest snapshot.
+As a consequence, you can be off the network (or disconnected
+from the network share) after ``branch`` completes but you'll
+still be able to ``log`` and ``diff`` the history of the
+branch as much as you want. Furthermore, these operations
+are quick as the history is stored locally.
+
+Note that Bazaar uses smart compression technology to
+minimize the amount of disk space required to store version
+history. In many cases, the complete history of a project
+will take up less disk space than the working copy of
+the latest version.
+
+As explained in later chapters, Bazaar also has support for
+`lightweight checkouts <#getting-a-lightweight-checkout>`_
+of a branch, i.e. working trees with
+no local storage of history. Of course, disconnected usage
+is not available then but that's a tradeoff you can decide
+to make if local disk space is really tight for you. Support for
+limited lookback into history - *history horizons* - is
+currently under development as well.
+
+Viewing branch information
+--------------------------
+
+If you wish to see information about a branch including where it came from,
+use the ``info`` command. For example::
+
+ bzr info cool
+
+If no branch is given, information on the current branch is displayed.
diff --git a/doc/ru/user-guide/core_concepts.txt b/doc/ru/user-guide/core_concepts.txt
new file mode 100644
index 0000000..b8eb15c
--- /dev/null
+++ b/doc/ru/user-guide/core_concepts.txt
@@ -0,0 +1,115 @@
+Основные концепции
+==================
+
+Простая модель для пользователя
+-------------------------------
+
+Для использования Bazaar нужно понимать четыре основные концепции:
+
+* **Ревизия** - снимок файлов с которыми вы работаете.
+
+* **Рабочее дерево** - каталог содержащий файлы и каталоги под контролем версий
+
+* **Ветка** - упорядоченный набор ревизий, описывающий историю набора файлов.
+
+* **Репозиторий** - хранилище ревизий.
+
+Давайте рассмотрим каждую концепцию более детально.
+
+Ревизия
+-------
+
+Ревизия - это *снимок* состояния дерева файлов и каталогов включающий их
+содержимое и форму. С ревизией так же связаны некоторые мета-данные, например:
+
+* Кто зафиксировал ревизию
+* Когда ревизия была зафиксирована
+* Комментарий к ревизии
+* Родительские ревизии от которых была унаследована данная ревизия
+
+Ревизии не изменяются и могут быть глобально и уникально идентифицированы
+*идентификатором ревизии*. Пример идентификатора::
+
+ pqm@pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz
+
+Идентификаторы ревизий создаются во время фиксации, или, в случае импорта из
+других систем, в момент импорта. Хотя идентификаторы ревизий необходимы для
+внутреннего использования и интеграции с внешними инструментами, специфичные
+для веток *номера ревизий* предпочтительны для людей.
+
+Номера ревизий - это разделенные точками десятичные идентификаторы, такие как
+1, 42 и 2977.1.59, которые отслеживают путь через граф номеров ревизий на
+ветке. Номера ревизий обычно короче чем идентификаторы ревизий и, в пределах
+одной ветки, могут сравниваться друг с другом для получения картины их
+отношений. Например, ревизия 10 - это основная ревизия (см. ниже) следующая
+непосредственно после ревизии 9. Номера ревизий создаются налету, при
+выполнении каждой команды, т.к. они зависят от ревизии являющейся верхушкой
+(т.е. самой последней ревизией) на ветке.
+
+Смотрите `Определение ревизий`_ в приложениях для более детального описания
+огромного количества методов задания ревизий и их диапазонов в Bazaar и
+`Понимание номеров ревизий`_ для более детального описания нумерации ревизий.
+
+.. *TODO: добавить диаграмму*
+
+Рабочее дерево
+--------------
+
+Рабочее дерево - это *каталог под контролем версий* содержащий файлы которые
+может редактировать пользователь. Рабочее дерево связано с *веткой*.
+
+Многие команды используют рабочее дерево как контекст, например ``commit``
+создает новую ревизию используя текущее содержимое файлов в рабочем дереве.
+
+.. *TODO: добавить диаграмму*
+
+Ветка
+-----
+
+В простейшем случае, ветка - это *упорядоченная серия ревизий*. Самая последняя
+ревизия известна как *верхушка*.
+
+Ветки могут быть разделены и *объединены* обратно, формируя *граф* ревизий.
+Технически, граф показывает прямые отношения (между родительской и дочерними
+ревизиями) и не имеет петель, и известен как *направленный ациклический граф*
+(directed acyclic graph (DAG)).
+
+Но не стоит бояться этого названия. Основные вещи которые нужно помнить:
+
+* Основная линия разработки внутри графа называется *основная линия*,
+ или просто *левая сторона*.
+
+* Ветка может иметь другие линии разработки и в этом случае они начинаются
+ в одной точке и заканчиваются в другой.
+
+.. *TODO: добавить диаграмму*
+
+Репозиторий
+-----------
+
+Репозиторий - это просто *хранилище ревизий*. В простейшем случае, каждая ветка
+имеет свой собственный репозиторий. В других случаях имеет смысл разделять
+репозиторий между ветками для оптимизации дискового пространства.
+
+.. *TODO: добавить диаграмму*
+
+Складывая концепции вместе
+--------------------------
+
+Как только вы поняли описанные выше концепции, различные пути использования
+Bazaar станут более понятными. Простейший способ использования Bazaar - это
+использовать *самостоятельное дерево*, совмещающее рабочее дерево, ветку и
+репозиторий в одном месте. Другие часто используемые сценарии включают:
+
+* `Разделяемые репозитории <#a-reminder-about-shared-repositories>`_ -
+ рабочее дерево и ветка находятся вместе, но репозиторий находится в
+ каталоге выше.
+
+* `Стек веток <#using-stacked-branches>`_ - ветка хранит только уникальные
+ для нее ревизии и использует родительский репозиторий для общих ревизий.
+
+* `Легковесные рабочие копии <#getting-a-lightweight-checkout>`_ -
+ ветка хранится в другом месте по сравнению с рабочим деревом.
+
+Лучший путь для использования Bazaar конечно зависит от ваших потребностей.
+Давайте дальше рассмотрим некоторые часто употребляемые способы использования.
diff --git a/doc/ru/user-guide/images/workflows_centralized.png b/doc/ru/user-guide/images/workflows_centralized.png
new file mode 100644
index 0000000..f964fe0
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_centralized.png
Binary files differ
diff --git a/doc/ru/user-guide/images/workflows_centralized.svg b/doc/ru/user-guide/images/workflows_centralized.svg
new file mode 100644
index 0000000..4a09de0
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_centralized.svg
@@ -0,0 +1,1542 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_centralized.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_centralized.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.4142136"
+ inkscape:cx="536.99132"
+ inkscape:cy="369.73871"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1024"
+ inkscape:window-height="712"
+ inkscape:window-x="-4"
+ inkscape:window-y="-4" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr checkout</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(492.85715,-2.8571472)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.71429"
+ y="191.52307"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="777.71429"
+ y="191.52307">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="819.5625"
+ y="191.21948"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="819.5625"
+ y="191.21948">bzr update</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.29065037;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 539.95542,466.93556 L 415.85387,476.71718 L 426.49116,461.93102 L 358.1094,466.70812 C 358.1094,466.70812 347.47211,481.94916 346.96566,481.94916 C 346.45858,481.94916 322.14533,462.15846 322.14533,462.15846 C 322.14533,462.15846 379.38334,441.45772 379.88978,441.45772 C 379.38334,441.00284 369.25249,456.01673 369.25249,456.24417 L 448.27282,451.23935 L 437.63489,466.48068 L 551.09912,456.92649 L 539.95542,466.93556 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(51.511043,348.5966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="334.36819"
+ y="540.97681"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="334.36819"
+ y="540.97681">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="369.5625"
+ y="544.09448"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="369.5625"
+ y="544.09448">bzr commit</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ru/user-guide/images/workflows_gatekeeper.png b/doc/ru/user-guide/images/workflows_gatekeeper.png
new file mode 100644
index 0000000..eded8a4
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_gatekeeper.png
Binary files differ
diff --git a/doc/ru/user-guide/images/workflows_gatekeeper.svg b/doc/ru/user-guide/images/workflows_gatekeeper.svg
new file mode 100644
index 0000000..6490454
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_gatekeeper.svg
@@ -0,0 +1,2137 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_gatekeeper.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_manualpqm.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient7932"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7934"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7936"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7938"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7940"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7942"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7944"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient7946"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7948"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7950"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient7952"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7954"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7956"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7958"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7960"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient7962"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient7964"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7966"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient7968"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient7990"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <radialGradient
+ xlink:href="#linearGradient1861"
+ r="26.285225"
+ inkscape:collect="always"
+ id="radialGradient1887"
+ fy="44.906904"
+ fx="34.609807"
+ cy="45.317611"
+ cx="33.865884"
+ gradientTransform="scale(1.3025634,0.767717)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1861"
+ r="27.313507"
+ inkscape:collect="always"
+ id="radialGradient1885"
+ fy="96.522109"
+ fx="44.745902"
+ cy="96.948882"
+ cx="45.838441"
+ gradientTransform="scale(1.0963096,0.9121511)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="69.990188"
+ y1="60.176033"
+ xlink:href="#linearGradient1864"
+ x2="54.084046"
+ x1="51.210938"
+ inkscape:collect="always"
+ id="linearGradient1883"
+ gradientTransform="scale(1.2343409,0.8101489)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1858">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop1859" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop1860" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1861">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop1862" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1863" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1864">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop1865" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1866" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1867">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop1868" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1869" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11180">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop11182" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11184" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11174">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop11176" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11178" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11168">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop11170" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11172" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11162">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop11164" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop11166" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="559.94128"
+ inkscape:cy="472.46874"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1416"
+ inkscape:window-height="825"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,39.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,227.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(635.63525,491.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="73.4375"
+ y="510.12573"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="73.4375"
+ y="510.12573">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(466.18527,201.5491)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="751.04242"
+ y="395.37573"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="751.04242"
+ y="395.37573">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="778.89062"
+ y="392.32886"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="778.89062"
+ y="392.32886"
+ id="tspan2963">make changes</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.52894235;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 578.13978,492.35651 L 518.11306,536.64644 L 515.93459,528.2361 L 482.53728,552.4378 C 482.53728,552.4378 484.9546,560.99862 484.68867,561.16617 C 484.42242,561.33391 461.26447,562.83001 461.26447,562.83001 C 461.26447,562.83001 480.44933,537.04707 480.71524,536.87954 C 480.21048,536.89659 482.77445,545.21473 482.89387,545.28997 L 521.75768,517.49359 L 524.17482,526.05472 L 578.73553,485.35896 L 578.13978,492.35651 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(449.56027,418.37723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="732.41742"
+ y="611.97729"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="732.41742"
+ y="611.97729">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="768.26562"
+ y="608.23511"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="768.26562"
+ y="608.23511">request merge</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="75.5625"
+ y="228.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="75.5625"
+ y="228.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="556.98438"
+ y="165.64139"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="556.98438"
+ y="165.64139">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-477.33182,37.826027)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.0657387,0,0,1.0382501,-36.482679,-19.544354)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.27460909;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path7875"
+ d="M 313.49127,554.98551 L 266.8349,508.88833 L 275.69462,507.21539 L 250.19978,481.56811 C 250.19978,481.56811 241.18156,483.42447 241.00507,483.22026 C 240.82835,483.0158 239.25232,465.23179 239.25232,465.23179 C 239.25232,465.23179 266.41286,479.96469 266.58935,480.16889 C 266.57138,479.78127 257.8088,481.75026 257.72954,481.84196 L 287.01109,511.6872 L 277.99254,513.54344 L 320.8627,555.44302 L 313.49127,554.98551 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <g
+ id="g7884"
+ transform="translate(322.22009,479.97324)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient7932);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path7886"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient7934);fill-opacity:1"
+ id="g7888">
+ <path
+ style="fill:url(#linearGradient7936);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path7890"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient7938);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path7892"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient7940);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path7894"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient7942);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient7944);stroke-width:1.44734821pt"
+ id="rect7896"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient7946);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path7898"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient7948);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path7900"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient7950);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect7902"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient7952);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient7954);stroke-width:1.4649456pt"
+ id="rect7904"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient7956);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path7906"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g7908">
+ <path
+ style="fill:url(#linearGradient7958);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path7910"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient7960);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path7912"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient7962);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path7914"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient7964);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path7916"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient7966);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path7918"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient7968);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path7920"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient7990);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path7922"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text7924"><tspan
+ id="tspan7926">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text7928"><tspan
+ id="tspan7930">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g11201"
+ transform="translate(224.98935,560.87966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11204"
+ d="M 61.208646,74.540863 C 65.958047,79.724425 68.980394,89.011639 75.672733,89.01164 C 82.14919,87.211791 83.012718,71.805094 83.876245,68.493375 C 76.536261,73.532948 68.980395,76.412704 61.208646,74.540863 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,-0.8485902,18.11889)"
+ style="fill:#ebd5bb;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path11206"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#354b63;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path11208"
+ d="M 32.210275,101.34753 C 31.819634,126.54379 96.449036,129.42515 96.292736,101.34753 C 97.837516,79.018786 86.732289,66.323086 83.972618,68.481556 C 82.571377,69.577533 82.050742,93.917319 72.58281,88.318677 C 67.97993,85.596878 62.831472,75.141814 60.578865,74.794949 C 57.17979,74.271545 50.671042,71.519447 44.693328,66.368738 C 43.125035,65.017418 32.739724,78.907727 32.210275,101.34753 z " />
+ <path
+ style="fill:#7e5429;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccscc"
+ id="path14564"
+ d="M 67.304802,16.686453 C 54.985668,-4.2976037 31.742548,13.847204 34.832083,38.13111 C 28.606909,39.936495 13.38594,55.735942 54.610465,51.217079 C 72.973357,49.204214 127.11969,28.718598 84.679736,22.863615 C 78.797006,1.2972292 67.040662,6.1031815 67.304802,16.686453 z " />
+ <path
+ style="fill:url(#linearGradient1883);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1879"
+ d="M 89.582928,41.074792 C 78.886738,46.748497 62.561318,51.815798 53.926678,52.762292 C 47.018518,53.519536 42.160188,53.578455 38.114178,53.356042 C 39.550848,66.152312 50.849068,76.168541 64.707928,76.168542 C 79.538378,76.168542 91.582928,64.747093 91.582928,50.668542 C 91.582928,47.276803 90.850878,44.035951 89.582928,41.074792 z " />
+ <path
+ style="fill:url(#radialGradient1885);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1884"
+ d="M 43.031249,70.1875 C 35.995246,80.448202 32.902215,93.581638 34.156249,105.875 C 40.334493,118.62839 56.831543,120.43683 69.499999,119.875 C 80.494576,119.32475 94.949065,113.14258 93.695531,100.00002 C 93.939855,90.023763 92.261916,78.780004 84.874999,71.5 C 82.650684,78.396104 83.536195,89.443626 74.999999,91.84375 C 65.062996,91.017122 64.05284,76.914438 54.283675,75.750529 C 50.352102,75.051855 46.009593,69.547093 43.031249,70.1875 z " />
+ <path
+ style="fill:url(#radialGradient1887);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1886"
+ d="M 51.968749,10.15625 C 40.703741,13.843837 36.038494,27.433868 37.531249,38.375 C 35.900906,41.584912 25.71302,45.254989 31.843749,49.03125 C 53.068339,53.154256 75.12687,46.221276 93.715523,36.077723 C 100.42684,33.740896 99.810666,26.846559 92.384918,26.66513 C 86.324151,26.558371 81.674394,23.81643 81.165374,17.307044 C 79.826948,13.582045 74.107596,6.6890987 71.01108,12.623276 C 71.073069,19.511996 65.891703,20.102559 63.230392,14.042893 C 60.468574,10.851605 56.135557,9.1882781 51.968749,10.15625 z " />
+ </g>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2488"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(82.857147,474.9866)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="365.71429"
+ y="668.60229"
+ id="text2490"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2492"
+ x="365.71429"
+ y="668.60229">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="401.5625"
+ y="665.76636"
+ id="text2494"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2496"
+ x="401.5625"
+ y="665.76636">accept or reject</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ru/user-guide/images/workflows_localcommit.png b/doc/ru/user-guide/images/workflows_localcommit.png
new file mode 100644
index 0000000..f6d4f83
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_localcommit.png
Binary files differ
diff --git a/doc/ru/user-guide/images/workflows_localcommit.svg b/doc/ru/user-guide/images/workflows_localcommit.svg
new file mode 100644
index 0000000..2e7ad85
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_localcommit.svg
@@ -0,0 +1,1575 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_localcommit.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_localcommit.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient8493"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient8491"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient8485">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop8487" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop8489" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.70710678"
+ inkscape:cx="503.09779"
+ inkscape:cy="201.79714"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1024"
+ inkscape:window-height="712"
+ inkscape:window-x="-4"
+ inkscape:window-y="-4" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="763.75"
+ y="188.09448"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="35.529999"
+ inkscape:export-ydpi="35.529999"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="763.75"
+ y="188.09448">bzr commit --local</tspan><tspan
+ sodipodi:role="line"
+ x="763.75"
+ y="228.09448"
+ id="tspan7922" /></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="801.4375"
+ y="609.46948"
+ id="text7881"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan7883"
+ x="801.4375"
+ y="609.46948">bzr unbind</tspan><tspan
+ sodipodi:role="line"
+ x="801.4375"
+ y="641.46948"
+ id="tspan8507">bzr commit</tspan><tspan
+ sodipodi:role="line"
+ x="801.4375"
+ y="673.46948"
+ id="tspan8511">bzr bind</tspan></text>
+ <g
+ id="g7903"
+ transform="translate(21.8125,50.285718)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path7897"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text7899"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan7901"
+ sodipodi:role="line">1</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="351.375"
+ y="272.69269"
+ id="text7908"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan7910"
+ x="351.375"
+ y="272.69269">bzr checkout</tspan></text>
+ <g
+ id="g7912"
+ transform="translate(438.71429,-31.85714)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path7914"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text7916"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan7918"
+ sodipodi:role="line">2</tspan></text>
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.58159733;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path8495"
+ d="M 530.64409,443.90791 L 411.93077,455.56731 L 422.10621,437.94266 L 356.69344,443.63682 C 356.69344,443.63682 346.51796,461.80368 346.0335,461.80368 C 345.54844,461.80368 322.2908,438.21377 322.2908,438.21377 C 322.2908,438.21377 377.0437,413.53911 377.52817,413.53911 C 377.0437,412.99691 367.35272,430.89301 367.35272,431.16411 L 442.94217,425.19852 L 432.76613,443.36572 L 541.30393,431.97742 L 530.64409,443.90791 z " />
+ <g
+ id="g8497"
+ transform="translate(446.57144,390.28572)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path8499"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text8501"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan8503"
+ sodipodi:role="line">2</tspan></text>
+ </g>
+ <g
+ id="g8513"
+ transform="translate(59.142865,311.71429)">
+ <path
+ transform="matrix(0.5652174,0,0,0.5909091,121.25465,81.649039)"
+ d="M 340 221.23734 A 32.857143 31.428572 0 1 1 274.28571,221.23734 A 32.857143 31.428572 0 1 1 340 221.23734 z"
+ sodipodi:ry="31.428572"
+ sodipodi:rx="32.857143"
+ sodipodi:cy="221.23734"
+ sodipodi:cx="307.14285"
+ id="path8515"
+ style="fill:#000000"
+ sodipodi:type="arc" />
+ <text
+ sodipodi:linespacing="125%"
+ id="text8517"
+ y="225.53198"
+ x="286.3125"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ xml:space="preserve"><tspan
+ y="225.53198"
+ x="286.3125"
+ id="tspan8519"
+ sodipodi:role="line">3</tspan></text>
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:100%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="389.375"
+ y="534.40698"
+ id="text8525"
+ sodipodi:linespacing="100%"><tspan
+ sodipodi:role="line"
+ id="tspan8527"
+ x="389.375"
+ y="534.40698">bzr commit</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ru/user-guide/images/workflows_peer.png b/doc/ru/user-guide/images/workflows_peer.png
new file mode 100644
index 0000000..d1cfa71
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_peer.png
Binary files differ
diff --git a/doc/ru/user-guide/images/workflows_peer.svg b/doc/ru/user-guide/images/workflows_peer.svg
new file mode 100644
index 0000000..f68a774
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_peer.svg
@@ -0,0 +1,1589 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_peer.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_peer.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="536.99132"
+ inkscape:cy="369.73871"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1759"
+ inkscape:window-height="875"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ id="g5256"
+ transform="translate(601.5744,309.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(541.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(111.5744,317.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,300.80614,215.0989)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 357.16674,263.66524 L 470.27399,251.12251 L 460.57906,270.08242 L 522.9028,263.95688 C 522.9028,263.95688 532.59773,244.41369 533.05931,244.41369 C 533.52148,244.41369 555.68079,269.79078 555.68079,269.79078 C 555.68079,269.79078 503.51355,296.33479 503.05197,296.33479 C 503.51355,296.91808 512.74689,277.66616 512.74689,277.37453 L 440.72705,283.79207 L 450.42255,264.24852 L 347.01023,276.4996 L 357.16674,263.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="635.5625"
+ y="201.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="635.5625"
+ y="201.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(318.85715,7.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="601.71429"
+ y="199.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="601.71429"
+ y="199.52307">2</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.49513507;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 426.28539,558.28183 L 482.38891,565.59894 L 477.58003,554.5382 L 508.49388,558.1117 C 508.49388,558.1117 513.30276,569.51271 513.53172,569.51271 C 513.76096,569.51271 524.75243,554.70834 524.75243,554.70834 C 524.75243,554.70834 498.87641,539.22321 498.64746,539.22321 C 498.87641,538.88294 503.45634,550.11403 503.45634,550.28417 L 467.73303,546.54033 L 472.54219,557.94156 L 421.24757,550.79458 L 426.28539,558.28183 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-194.48896,372.41254)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="87.591393"
+ y="566.02826"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="87.591393"
+ y="566.02826">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="119.03906"
+ y="543.19232"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="119.03906"
+ y="543.19232">merge changes</tspan><tspan
+ sodipodi:role="line"
+ x="119.03906"
+ y="583.19232"
+ id="tspan2716">from peer</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2670"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-187.14285,5.361605)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="94.539062"
+ y="198.97729"
+ id="text2672"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2674"
+ x="94.539062"
+ y="198.97729">1</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="129.5625"
+ y="195.43823"
+ id="text2676"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2678"
+ x="129.5625"
+ y="195.43823">start project</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2680"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(-20.189728,217.62723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="261.83594"
+ y="411.22729"
+ id="text2682"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2684"
+ x="261.83594"
+ y="411.22729">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="294.51562"
+ y="388.40698"
+ id="text2686"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2688"
+ x="294.51562"
+ y="388.40698">record</tspan><tspan
+ sodipodi:role="line"
+ x="294.51562"
+ y="428.40698"
+ id="tspan2712">changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2690"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(321.8001,372.41254)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="603.88049"
+ y="566.02826"
+ id="text2692"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2694"
+ x="603.88049"
+ y="566.02826">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="635.32812"
+ y="543.19232"
+ id="text2696"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2698"
+ x="635.32812"
+ y="543.19232">merge changes</tspan><tspan
+ sodipodi:role="line"
+ x="635.32812"
+ y="583.19232"
+ id="tspan2718">from peer</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2700"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(462.85715,216.65848)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="744.88281"
+ y="410.25854"
+ id="text2702"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2704"
+ x="744.88281"
+ y="410.25854">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.5625"
+ y="387.43823"
+ id="text2706"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2708"
+ x="777.5625"
+ y="387.43823">record</tspan><tspan
+ sodipodi:role="line"
+ x="777.5625"
+ y="427.43823"
+ id="tspan2714">changes</tspan></text>
+ <path
+ inkscape:export-ydpi="41.964157"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_centralized.png"
+ d="M 515.71461,505.61603 L 459.61109,512.93314 L 464.41997,501.8724 L 433.50612,505.4459 C 433.50612,505.4459 428.69724,516.84691 428.46828,516.84691 C 428.23904,516.84691 417.24757,502.04254 417.24757,502.04254 C 417.24757,502.04254 443.12359,486.55741 443.35254,486.55741 C 443.12359,486.21714 438.54366,497.44823 438.54366,497.61837 L 474.26697,493.87453 L 469.45781,505.27576 L 520.75243,498.12878 L 515.71461,505.61603 z "
+ id="path2710"
+ sodipodi:nodetypes="cccccccccccc"
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.49513507;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1" />
+ </g>
+</svg>
diff --git a/doc/ru/user-guide/images/workflows_pqm.png b/doc/ru/user-guide/images/workflows_pqm.png
new file mode 100644
index 0000000..3cfe139
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_pqm.png
Binary files differ
diff --git a/doc/ru/user-guide/images/workflows_pqm.svg b/doc/ru/user-guide/images/workflows_pqm.svg
new file mode 100644
index 0000000..8c6dcbf
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_pqm.svg
@@ -0,0 +1,1794 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_pqm.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_pqm.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient7934"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ id="linearGradient1858">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop1859" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop1860" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1861">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop1862" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1863" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1864">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop1865" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1866" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1867">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop1868" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1869" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11180">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop11182" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11184" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11174">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop11176" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11178" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11168">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop11170" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop11172" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient11162">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop11164" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop11166" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1"
+ inkscape:cx="559.94128"
+ inkscape:cy="392.13154"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1416"
+ inkscape:window-height="825"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2791"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(562.85715,227.14285)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="844.88281"
+ y="420.74292"
+ id="text2793"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2795"
+ x="844.88281"
+ y="420.74292">3</tspan></text>
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,39.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,227.66157)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(593.63525,509.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,417.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,874.16045,452.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="92.546875"
+ y="509.71948"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="92.546875"
+ y="509.71948">Server</tspan><tspan
+ sodipodi:role="line"
+ x="92.546875"
+ y="569.71948"
+ id="tspan2803">(PQM)</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(558.85715,89.5491)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="841.25"
+ y="283.37573"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="841.25"
+ y="283.37573">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="874.89062"
+ y="264.32886"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="874.89062"
+ y="264.32886"
+ id="tspan2788">make</tspan><tspan
+ sodipodi:role="line"
+ x="874.89062"
+ y="304.32886"
+ id="tspan2815">changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(449.56027,432.37723)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="732.41742"
+ y="625.97729"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="732.41742"
+ y="625.97729">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="768.26562"
+ y="622.23511"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="768.26562"
+ y="622.23511">accept or reject</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="75.5625"
+ y="228.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="75.5625"
+ y="228.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="556.98438"
+ y="165.64139"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="556.98438"
+ y="165.64139">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-477.33182,37.826027)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.0657387,0,0,1.0382501,-36.482679,-19.544354)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <g
+ id="g11201"
+ transform="translate(224.98935,560.87966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2488"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(44.857147,386.9866)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="327.71429"
+ y="580.60229"
+ id="text2490"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2492"
+ x="327.71429"
+ y="580.60229">5</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="363.5625"
+ y="577.76636"
+ id="text2494"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ id="tspan2496"
+ x="363.5625"
+ y="577.76636">request merge</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path2801"
+ d="M 530.83326,472.52373 L 417.72601,485.06646 L 427.42094,466.10655 L 365.0972,472.23209 C 365.0972,472.23209 355.40227,491.77528 354.94069,491.77528 C 354.47852,491.77528 332.31921,466.39819 332.31921,466.39819 C 332.31921,466.39819 384.48645,439.85418 384.94803,439.85418 C 384.48645,439.27089 375.25311,458.52281 375.25311,458.81444 L 447.27295,452.3969 L 437.57745,471.94045 L 540.98977,459.68937 L 530.83326,472.52373 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="878.89062"
+ y="396.40698"
+ id="text2811"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_manualpqm.png"
+ inkscape:export-xdpi="38.384644"
+ inkscape:export-ydpi="38.384644"><tspan
+ sodipodi:role="line"
+ x="878.89062"
+ y="396.40698"
+ id="tspan2813">request</tspan><tspan
+ sodipodi:role="line"
+ x="878.89062"
+ y="436.40698"
+ id="tspan2817">review</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ru/user-guide/images/workflows_shared.png b/doc/ru/user-guide/images/workflows_shared.png
new file mode 100644
index 0000000..331feb9
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_shared.png
Binary files differ
diff --git a/doc/ru/user-guide/images/workflows_shared.svg b/doc/ru/user-guide/images/workflows_shared.svg
new file mode 100644
index 0000000..762155e
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_shared.svg
@@ -0,0 +1,1594 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_shared.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_shared.png"
+ inkscape:export-xdpi="49.419998"
+ inkscape:export-ydpi="49.419998">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="radialGradient5536"
+ gradientUnits="userSpaceOnUse"
+ cx="42.007257"
+ cy="39.007645"
+ fx="42.280806"
+ fy="39.410465"
+ r="11.574221" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5540"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5542"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5544"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5546"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="25.220815"
+ y1="178.48862"
+ x2="25.220815"
+ y2="234.26866" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5548"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ x1="51.460928"
+ y1="269.85831"
+ x2="-16.224496"
+ y2="176.28694" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient893"
+ id="linearGradient5550"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1870691,0.842411)"
+ x1="146.69923"
+ y1="224.57898"
+ x2="74.533693"
+ y2="81.477602" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5552"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ x1="45.685757"
+ y1="110.4447"
+ x2="41.967061"
+ y2="232.24952" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5554"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ x1="-77.726178"
+ y1="208.43991"
+ x2="95.644441"
+ y2="11.699047" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1133"
+ id="radialGradient5556"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ cx="60.004654"
+ cy="56.485935"
+ fx="72.107883"
+ fy="39.288476"
+ r="68.589222" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5558"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ x1="92.437968"
+ y1="-3.9104078"
+ x2="27.674331"
+ y2="91.07699" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5560"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ x1="39.810948"
+ y1="90.197025"
+ x2="17.876529"
+ y2="113.71949" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5562"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.329144,0.7523639)"
+ x1="39.690614"
+ y1="49.507656"
+ x2="70.224305"
+ y2="20.481863" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5564"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ x1="35.190362"
+ y1="76.277559"
+ x2="8.346058"
+ y2="105.42543" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient888"
+ id="linearGradient5566"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ x1="141.60217"
+ y1="228.39311"
+ x2="88.447016"
+ y2="133.54711" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient902"
+ id="linearGradient5568"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ x1="101.10657"
+ y1="177.77768"
+ x2="95.100155"
+ y2="173.03153" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5570"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ x1="88.755695"
+ y1="169.09755"
+ x2="88.996957"
+ y2="182.99154" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1317"
+ id="linearGradient5572"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.223869,0.8170809)"
+ x1="111.49758"
+ y1="131.25248"
+ x2="107.04918"
+ y2="148.78619" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient892"
+ id="linearGradient5574"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ x1="31.449743"
+ y1="203.499"
+ x2="31.617281"
+ y2="251.21892" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="39.648127"
+ inkscape:collect="always"
+ id="radialGradient2797"
+ fy="101.92288"
+ fx="50.092871"
+ cy="102.70191"
+ cx="49.760482"
+ gradientTransform="scale(1.1222336,0.8910801)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="35.284406"
+ inkscape:collect="always"
+ id="radialGradient2791"
+ fy="32.061308"
+ fx="81.553592"
+ cy="33.402904"
+ cx="80.599566"
+ gradientTransform="scale(0.8352269,1.1972794)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="67.164412"
+ y1="53.505203"
+ xlink:href="#linearGradient4376"
+ x2="63.804663"
+ x1="64.786456"
+ inkscape:collect="always"
+ id="linearGradient2789"
+ gradientTransform="scale(1.1424512,0.8753109)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.8"
+ inkscape:cx="578.40513"
+ inkscape:cy="404.22798"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1405"
+ inkscape:window-height="869"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ inkscape:label="Layer 1"
+ id="g4996"
+ transform="matrix(0.331077,0,0,0.2676656,75.992157,230.68349)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <g
+ transform="matrix(2.674162,0,0,2.674162,-826.248,-323.8239)"
+ id="g6052">
+ <path
+ style="fill:#c7c7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:6.11299896;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="czcczzz"
+ id="path1306"
+ d="M 362.77592,187.283 C 360.50343,190.98677 361.20593,367.68763 364.14011,374.65173 C 366.46268,380.1642 441.02381,442.12988 444.93699,443.78694 C 495.35017,443.444 529.34176,425.0858 534.99109,415.38735 C 537.14042,403.1889 535.31621,215.19709 533.25552,211.25359 C 531.47859,207.85312 436.04893,173.6386 432.71615,172.86054 C 429.71763,172.16052 365.30189,183.1661 362.77592,187.283 z " />
+ <path
+ style="fill:#ffffff;fill-opacity:0.54385968;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2066"
+ d="M 366.42857,190.93361 C 391.19048,201.4098 418.60601,218.30739 446.22506,231.64072 C 472.394,225.42153 510.2022,217.10972 529.24981,213.77639 C 504.726,221.39543 472.52022,228.51448 447.99641,236.13353 C 446.56784,293.51448 447.257,380.45861 445.82843,437.83956 C 445.11414,379.98242 443.14285,291.6479 442.42856,233.79075 C 415.99999,219.50504 390,206.64789 366.42857,190.93361 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path4356"
+ d="M 519.99794,379.97737 C 510.93834,392.99882 482.41849,399.43361 468.8726,394.16864 C 471.21835,393.5424 516.96143,380.96883 519.99794,379.97737 z " />
+ <g
+ transform="translate(2.035534,15.20712)"
+ id="g4374">
+ <path
+ style="fill:#ffffff;fill-opacity:0.39473685;fill-rule:evenodd;stroke:none;stroke-width:1.01199996;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path4362"
+ d="M 471.29127,340.59039 L 513.55921,324.30516 C 517.9002,325.84805 517.04588,332.27818 517.04588,332.27818 L 510.46155,334.58088 C 510.46155,334.58088 501.26764,349.01224 484.93096,343.36795 C 484.93096,343.36795 472.7787,345.52605 471.29127,340.59039 z " />
+ <path
+ style="fill:#606060;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1.11199999;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path2826"
+ d="M 471.66824,335.10501 C 485.70133,331.45482 499.73443,327.80464 513.76752,324.15445 C 514.30594,326.13864 514.34437,328.99782 513.50779,330.48201 C 511.36566,331.50652 507.10221,332.35425 504.96008,333.37876 C 498.80357,339.27354 493.45917,339.80363 483.65919,338.95243 C 479.87505,339.74603 476.0909,340.36284 472.30676,341.15644 C 471.15285,338.85897 470.82215,337.90248 471.66824,335.10501 z " />
+ </g>
+ <path
+ style="fill:#ffffff;fill-opacity:0.40350874;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path4423"
+ d="M 364.8671,189.69191 L 446.71991,235.61832 L 446.39149,441.00771 L 366.28132,373.53968 L 364.8671,189.69191 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5957"
+ d="M 515.24794,392.97737 C 505.81506,405.42036 486.94113,407.56087 476.3726,403.76831 C 478.1563,403.29212 512.93901,393.73127 515.24794,392.97737 z " />
+ <path
+ style="fill:#000000;fill-opacity:0.16228069;fill-rule:evenodd;stroke:none;stroke-width:0.25pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ sodipodi:nodetypes="ccc"
+ id="path5959"
+ d="M 508.24794,405.72737 C 502.79158,413.09279 492.2492,415.37141 483.8726,412.49343 C 484.991,412.19485 506.80021,406.20008 508.24794,405.72737 z " />
+ <path
+ style="fill:#fcfcfc;fill-opacity:0.44298245;fill-rule:evenodd;stroke:none;stroke-width:0.31200001;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccccc"
+ id="path5973"
+ d="M 522.875,227.86218 L 527.04289,228.4302 L 527.79289,326.56929 L 463.46862,344.54896 L 461.88388,339.34073 L 523.68934,322.86218 L 522.875,227.86218 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6026"
+ d="M 462.21967,264.23013 L 462.31434,266.99086 L 522.7929,249.54632 L 462.21967,264.23013 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6036"
+ d="M 461.33579,284.2059 L 461.43046,286.96663 L 521.90902,269.52209 L 461.33579,284.2059 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6038"
+ d="M 462.21967,302.64613 L 462.31434,305.40686 L 522.7929,287.96232 L 462.21967,302.64613 z " />
+ <path
+ style="opacity:1;color:#000000;fill:#000000;fill-opacity:0.22745098;fill-rule:evenodd;stroke:none;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.22807013;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="cccc"
+ id="path6040"
+ d="M 462.21967,320.79868 L 462.31434,323.55941 L 522.7929,306.11487 L 462.21967,320.79868 z " />
+ <path
+ style="opacity:1;color:#000000;fill:none;fill-opacity:0.75;fill-rule:evenodd;stroke:#9e9e9e;stroke-width:2.61199999;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;font-family:Bitstream Vera Sans"
+ sodipodi:nodetypes="ccc"
+ id="path5988"
+ d="M 522.55191,229.64344 L 462.03362,244.76045 L 462.53549,344.35813" />
+ </g>
+ </g>
+ <g
+ id="g5256"
+ transform="translate(601.5744,207.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <g
+ id="g5488"
+ transform="translate(601.5744,407.49165)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient5536);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path5490"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient5538);fill-opacity:1"
+ id="g5492">
+ <path
+ style="fill:url(#linearGradient5540);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5494"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5542);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path5496"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5544);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path5498"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient5546);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5548);stroke-width:1.44734821pt"
+ id="rect5500"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient5550);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path5502"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient5552);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5504"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient5554);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect5506"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient5556);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient5558);stroke-width:1.4649456pt"
+ id="rect5508"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient5560);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path5510"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g5512">
+ <path
+ style="fill:url(#linearGradient5562);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5514"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient5564);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path5516"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient5566);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path5518"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient5568);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path5520"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient5570);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path5522"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient5572);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path5524"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient5574);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path5526"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5528"><tspan
+ id="tspan5530">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text5532"><tspan
+ id="tspan5534">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g6024"
+ transform="matrix(-1,0,0,1,900.16045,422.61731)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192">
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path6027"
+ d="M 60.545133,72.847539 C 65.294534,78.031101 68.316881,87.318315 75.00922,87.318316 C 81.485677,85.518467 82.349205,70.11177 83.212732,66.800051 C 75.872748,71.839624 68.316882,74.71938 60.545133,72.847539 z " />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#d20000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path6029"
+ d="M 31.546762,99.654209 C 31.156121,124.85047 95.78552,127.73183 95.62922,99.654209 C 97.174007,77.325462 86.068776,64.629762 83.309105,66.788232 C 81.907864,67.884209 81.387229,92.223995 71.919297,86.625353 C 67.316417,83.903554 62.167959,73.44849 59.915352,73.101625 C 56.516277,72.578221 50.007529,69.826123 44.029815,64.675414 C 42.461522,63.324094 32.076211,77.214403 31.546762,99.654209 z " />
+ <path
+ style="fill:url(#radialGradient2797);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2796"
+ d="M 43.53125,77.3125 C 40.353026,86.016409 37.202011,96.366079 40.377303,105.23542 C 48.984655,117.18204 66.049398,117.25223 79.222417,115.04972 C 88.094278,113.47345 96.636121,105.87972 94.744454,96.188658 C 94.751182,88.561019 93.319573,80.643142 89.09375,74.1875 C 87.954705,81.120157 85.706152,92.347929 76.686643,91.786583 C 66.841974,89.84774 65.058803,76.33878 54.747596,75.105769 C 49.945701,71.530053 45.566465,69.110698 43.783935,76.852875 L 43.53125,77.3125 z " />
+ <path
+ transform="matrix(0.440859,0,0,0.441062,0.997459,16.38124)"
+ style="fill:#efd7c7;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path6032"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ transform="translate(2.509562,-4.432856e-2)"
+ style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccccc"
+ id="path3720"
+ d="M 56.980881,5.8426527 C 39.420698,8.0166254 30.552872,16.206245 24.211446,49.532095 C 14.512196,98.076517 21.871677,115.5525 32.990311,115.56714 C 17.54932,102.40769 63.877625,86.740105 56.295103,44.070713 C 68.4508,48.712358 94.51097,54.349644 95.164349,41.718703 C 97.176702,29.219492 88.64173,4.4775042 56.980881,5.8426527 z " />
+ <path
+ style="fill:url(#linearGradient2789);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2164"
+ d="M 60.687242,45.028999 C 62.530882,55.403773 61.180052,64.151015 58.312242,71.685249 C 61.630122,73.07804 65.296862,73.904 69.155992,73.903999 C 83.975322,73.903999 95.981712,62.468019 95.999742,48.403999 C 88.357632,52.885439 70.244092,48.678277 60.687242,45.028999 z " />
+ <path
+ style="fill:url(#radialGradient2791);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path2790"
+ d="M 52.174948,8.1325312 C 35.846775,12.141346 31.110158,30.475875 28.060647,44.840387 C 24.465246,64.767005 19.485139,85.90438 25.518698,105.82003 C 29.863591,114.87216 28.026452,106.52571 31.049538,102.11795 C 41.311249,87.323083 56.256862,73.307418 55.936774,53.886064 C 56.647391,49.398848 52.34734,38.640985 60.701717,42.254379 C 70.683443,45.202557 82.078811,49.011247 92.143698,44.632531 C 96.945103,37.45042 93.288237,27.137344 88.876323,20.399742 C 81.135092,8.5919962 65.300885,5.0194752 52.174948,8.1325312 z " />
+ </g>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.63842154;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path699"
+ d="M 319.16674,325.66524 L 432.27399,313.12251 L 422.57906,332.08242 L 484.9028,325.95688 C 484.9028,325.95688 494.59773,306.41369 495.05931,306.41369 C 495.52148,306.41369 517.68079,331.79078 517.68079,331.79078 C 517.68079,331.79078 465.51355,358.33479 465.05197,358.33479 C 465.51355,358.91808 474.74689,339.66616 474.74689,339.37453 L 402.72705,345.79207 L 412.42255,326.24852 L 309.01023,338.4996 L 319.16674,325.66524 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:48px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont;font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;line-height:125%"
+ x="140"
+ y="521.23737"
+ id="text7612"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan7614"
+ x="140"
+ y="521.23737">Server</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="359.5625"
+ y="261.21948"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan7879"
+ x="359.5625"
+ y="261.21948">bzr branch</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(42.857147,67.142853)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="325.71429"
+ y="259.52307"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="325.71429"
+ y="259.52307">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(492.85715,-2.8571472)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="777.71429"
+ y="191.52307"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="777.71429"
+ y="191.52307">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="819.5625"
+ y="179.59448"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="819.5625"
+ y="179.59448">bzr pull</tspan><tspan
+ sodipodi:role="line"
+ x="819.5625"
+ y="219.59448"
+ id="tspan2963">bzr merge</tspan></text>
+ <path
+ style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:4.29065037;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="cccccccccccc"
+ id="path9650"
+ d="M 539.95542,466.93556 L 415.85387,476.71718 L 426.49116,461.93102 L 358.1094,466.70812 C 358.1094,466.70812 347.47211,481.94916 346.96566,481.94916 C 346.45858,481.94916 322.14533,462.15846 322.14533,462.15846 C 322.14533,462.15846 379.38334,441.45772 379.88978,441.45772 C 379.38334,441.00284 369.25249,456.01673 369.25249,456.24417 L 448.27282,451.23935 L 437.63489,466.48068 L 551.09912,456.92649 L 539.95542,466.93556 z "
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(51.511043,348.5966)"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="334.36819"
+ y="540.97681"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="334.36819"
+ y="540.97681">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="369.5625"
+ y="544.09448"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="369.5625"
+ y="544.09448">bzr commit</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="61.5625"
+ y="240.09448"
+ id="text2965"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan2967"
+ x="61.5625"
+ y="240.09448">main branch</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="563.43756"
+ y="582.09442"
+ id="text2969"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="C:\devel\public_html\gigo-ice.org\scm\bazaar\wiki\workflows_shared.png"
+ inkscape:export-xdpi="42.227192"
+ inkscape:export-ydpi="42.227192"><tspan
+ sodipodi:role="line"
+ id="tspan2971"
+ x="563.43756"
+ y="582.09442">local branches</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006169;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path4930"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(1.9161749,0,0,1.0419298,-501.33182,49.826027)" />
+ <path
+ sodipodi:type="arc"
+ style="fill:none;fill-opacity:1;stroke:#0000ff;stroke-width:5.00006151;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ id="path7839"
+ sodipodi:cx="342"
+ sodipodi:cy="171.0945"
+ sodipodi:rx="66"
+ sodipodi:ry="35"
+ d="M 408 171.0945 A 66 35 0 1 1 276,171.0945 A 66 35 0 1 1 408 171.0945 z"
+ transform="matrix(2.1405493,0,0,1.0364644,-57.067817,396.76108)" />
+ </g>
+</svg>
diff --git a/doc/ru/user-guide/images/workflows_single.png b/doc/ru/user-guide/images/workflows_single.png
new file mode 100644
index 0000000..772909a
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_single.png
Binary files differ
diff --git a/doc/ru/user-guide/images/workflows_single.svg b/doc/ru/user-guide/images/workflows_single.svg
new file mode 100644
index 0000000..1d312a2
--- /dev/null
+++ b/doc/ru/user-guide/images/workflows_single.svg
@@ -0,0 +1,1079 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://web.resource.org/cc/"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="1052.3622"
+ height="744.09448"
+ id="svg2"
+ sodipodi:version="0.32"
+ inkscape:version="0.45.1"
+ version="1.0"
+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
+ sodipodi:docname="workflows_single.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="90"
+ inkscape:export-ydpi="90">
+ <defs
+ id="defs4">
+ <radialGradient
+ xlink:href="#linearGradient5992"
+ r="33.156250"
+ inkscape:collect="always"
+ id="radialGradient6000"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
+ fy="285.36218"
+ fx="495.50000"
+ cy="285.36218"
+ cx="495.50000" />
+ <linearGradient
+ y2="187.57059"
+ y1="225.40080"
+ xlink:href="#linearGradient5963"
+ x2="458.91232"
+ x1="383.95898"
+ inkscape:collect="always"
+ id="linearGradient5969"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient3586">
+ <stop
+ style="stop-color:#000000;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop3588" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop3590" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5963">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5965" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5967" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient5992">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1;"
+ offset="0"
+ id="stop5994" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0;"
+ offset="1"
+ id="stop5996" />
+ </linearGradient>
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient893"
+ x2="0.92957747"
+ x1="-2.3960868e-17"
+ id="linearGradient4284" />
+ <linearGradient
+ y2="-0.033519555"
+ y1="2.0837989"
+ xlink:href="#linearGradient893"
+ x2="0.99074072"
+ x1="-0.77314812"
+ id="linearGradient4283" />
+ <linearGradient
+ y2="1.8771822"
+ y1="-0.033741195"
+ xlink:href="#linearGradient902"
+ x2="0.48453596"
+ x1="0.47041038"
+ id="linearGradient2740"
+ gradientTransform="scale(0.997153,1.002855)" />
+ <linearGradient
+ y2="1.9025002"
+ y1="-0.043652620"
+ xlink:href="#linearGradient902"
+ x2="0.48481107"
+ x1="0.47042510"
+ id="linearGradient1506"
+ gradientTransform="scale(0.995847,1.004170)" />
+ <linearGradient
+ y2="1.8570156"
+ y1="-0.024853170"
+ xlink:href="#linearGradient902"
+ x2="0.48548824"
+ x1="0.47157744"
+ id="linearGradient1505"
+ gradientTransform="scale(0.997825,1.002180)" />
+ <linearGradient
+ y2="182.99154"
+ y1="169.09755"
+ xlink:href="#linearGradient892"
+ x2="88.996957"
+ x1="88.755695"
+ id="linearGradient1404"
+ gradientTransform="scale(1.3695887,0.7301462)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.34964636"
+ id="radialGradient1316"
+ fy="0.18269235"
+ fx="0.50352114"
+ cy="0.50000006"
+ cx="0.50000000" />
+ <radialGradient
+ xlink:href="#linearGradient1317"
+ r="0.41197181"
+ id="radialGradient1315"
+ fy="0.26666668"
+ fx="0.47535211"
+ cy="0.53333336"
+ cx="0.47887325" />
+ <linearGradient
+ y2="173.03153"
+ y1="177.77768"
+ xlink:href="#linearGradient902"
+ x2="95.100155"
+ x1="101.10657"
+ id="linearGradient1171"
+ gradientTransform="scale(1.3601783,0.7351977)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="1.8378206"
+ y1="-0.016295359"
+ xlink:href="#linearGradient902"
+ x2="0.48655096"
+ x1="0.47284532"
+ id="linearGradient1170"
+ gradientTransform="scale(0.998371,1.001632)" />
+ <linearGradient
+ y2="81.477602"
+ y1="224.57898"
+ xlink:href="#linearGradient893"
+ x2="74.533693"
+ x1="146.69923"
+ id="linearGradient1169"
+ gradientTransform="scale(1.1870691,0.842411)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="133.54711"
+ y1="228.39311"
+ xlink:href="#linearGradient888"
+ x2="88.447016"
+ x1="141.60217"
+ id="linearGradient1167"
+ gradientTransform="scale(1.1838753,0.8446836)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="148.78619"
+ y1="131.25248"
+ xlink:href="#linearGradient1317"
+ x2="107.04918"
+ x1="111.49758"
+ id="linearGradient1166"
+ gradientTransform="scale(1.223869,0.8170809)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="176.28694"
+ y1="269.85831"
+ xlink:href="#linearGradient888"
+ x2="-16.224496"
+ x1="51.460928"
+ id="linearGradient1157"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="234.26866"
+ y1="178.48862"
+ xlink:href="#linearGradient888"
+ x2="25.220815"
+ x1="25.220815"
+ id="linearGradient1156"
+ gradientTransform="scale(2.4217071,0.4129318)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="105.42543"
+ y1="76.277559"
+ xlink:href="#linearGradient892"
+ x2="8.346058"
+ x1="35.190362"
+ id="linearGradient1150"
+ gradientTransform="scale(1.3283861,0.7527932)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="20.481863"
+ y1="49.507656"
+ xlink:href="#linearGradient892"
+ x2="70.224305"
+ x1="39.690614"
+ id="linearGradient1148"
+ gradientTransform="scale(1.329144,0.7523639)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="113.71949"
+ y1="90.197025"
+ xlink:href="#linearGradient892"
+ x2="17.876529"
+ x1="39.810948"
+ id="linearGradient1146"
+ gradientTransform="scale(1.3207392,0.7571517)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="251.21892"
+ y1="203.499"
+ xlink:href="#linearGradient892"
+ x2="31.617281"
+ x1="31.449743"
+ id="linearGradient1144"
+ gradientTransform="scale(2.1051174,0.4750329)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="-0.45783132"
+ y1="3.3012049"
+ xlink:href="#linearGradient888"
+ x2="0.92957747"
+ x1="0.00000000"
+ id="linearGradient1141" />
+ <linearGradient
+ y2="232.24952"
+ y1="110.4447"
+ xlink:href="#linearGradient888"
+ x2="41.967061"
+ x1="45.685757"
+ id="linearGradient1140"
+ gradientTransform="scale(1.9102155,0.5235012)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="75.912531"
+ y1="375.92199"
+ xlink:href="#linearGradient1806"
+ x2="-268.25407"
+ x1="-249.72067"
+ id="linearGradient1138"
+ gradientTransform="scale(1.087146,0.9198397)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient1133"
+ r="68.589222"
+ id="radialGradient1132"
+ fy="39.288476"
+ fx="72.107883"
+ cy="56.485935"
+ cx="60.004654"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="11.699047"
+ y1="208.43991"
+ xlink:href="#linearGradient888"
+ x2="95.644441"
+ x1="-77.726178"
+ id="linearGradient905"
+ gradientTransform="scale(1.0964158,0.9120627)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ xlink:href="#linearGradient1806"
+ id="linearGradient901" />
+ <linearGradient
+ y2="91.07699"
+ y1="-3.9104078"
+ xlink:href="#linearGradient888"
+ x2="27.674331"
+ x1="92.437968"
+ id="linearGradient891"
+ gradientTransform="scale(1.2267534,0.8151598)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient888">
+ <stop
+ style="stop-color:#626262;stop-opacity:1.0000000;"
+ offset="0.0000000"
+ id="stop889" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop890" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient892">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop893" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop894" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient902">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="0.00000000"
+ id="stop903" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.22000000;"
+ offset="1.0000000"
+ id="stop904" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1098">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1099" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
+ offset="0.50000000"
+ id="stop1101" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
+ offset="0.59930235"
+ id="stop1102" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
+ offset="1.0000000"
+ id="stop1100" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1133">
+ <stop
+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
+ offset="0.00000000"
+ id="stop1134" />
+ <stop
+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
+ offset="0.76209301"
+ id="stop1136" />
+ <stop
+ style="stop-color:#375e82;stop-opacity:1.0000000;"
+ offset="1.0000000"
+ id="stop1135" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient1317">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52892560;"
+ offset="0.00000000"
+ id="stop1318" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.17355372;"
+ offset="0.50000000"
+ id="stop1320" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.00000000;"
+ offset="1.0000000"
+ id="stop1319" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient893">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop895" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop896" />
+ </linearGradient>
+ <radialGradient
+ xlink:href="#linearGradient1806"
+ r="11.574221"
+ id="radialGradient1977"
+ fy="39.410465"
+ fx="42.280806"
+ cy="39.007645"
+ cx="42.007257"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient1806">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.35051546;"
+ offset="0.0000000"
+ id="stop1807" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.13402061;"
+ offset="0.64999998"
+ id="stop3276" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop1808" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5281"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5283"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5285"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="5.5130484"
+ inkscape:collect="always"
+ id="radialGradient1828"
+ fy="61.38567"
+ fx="86.542037"
+ cy="61.38567"
+ cx="86.542037"
+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="11.123441"
+ inkscape:collect="always"
+ id="radialGradient1824"
+ fy="58.887858"
+ fx="118.06427"
+ cy="58.54025"
+ cx="117.17439"
+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="22.00904"
+ inkscape:collect="always"
+ id="radialGradient1822"
+ fy="87.892895"
+ fx="45.50637"
+ cy="88.322677"
+ cx="45.139623"
+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ xlink:href="#linearGradient4362"
+ r="18.836343"
+ inkscape:collect="always"
+ id="radialGradient1818"
+ fy="33.351633"
+ fx="48.40165"
+ cy="32.467054"
+ cx="48.40165"
+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ y2="74.834393"
+ y1="57.093738"
+ xlink:href="#linearGradient4376"
+ x2="50.203204"
+ x1="50.52668"
+ inkscape:collect="always"
+ id="linearGradient1815"
+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
+ gradientUnits="userSpaceOnUse" />
+ <linearGradient
+ id="linearGradient4384">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop4385" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4386" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4376">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop4377" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4378" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4362">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop4363" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop4364" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4358">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop4359" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop4360" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5538"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient5714"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ id="linearGradient6015">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
+ offset="0.0000000"
+ id="stop6017" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6019" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6009">
+ <stop
+ style="stop-color:#000000;stop-opacity:0.52645504;"
+ offset="0.0000000"
+ id="stop6011" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6013" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient6003">
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
+ offset="0.0000000"
+ id="stop6005" />
+ <stop
+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
+ offset="1.0000000"
+ id="stop6007" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient5997">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop5999" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop6001" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient1806"
+ id="linearGradient6037"
+ gradientUnits="userSpaceOnUse"
+ gradientTransform="scale(1.087146,0.9198397)"
+ x1="-249.72067"
+ y1="375.92199"
+ x2="-268.25407"
+ y2="75.912531" />
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient654"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient653"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient650">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop651" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop652" />
+ </linearGradient>
+ <linearGradient
+ y2="0.46093750"
+ y1="0.46093750"
+ xlink:href="#linearGradient650"
+ x2="1.16666818"
+ x1="1.22222710"
+ spreadMethod="repeat"
+ id="linearGradient9648"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ y2="0.53906250"
+ y1="0.53125000"
+ xlink:href="#linearGradient650"
+ x2="1.16666901"
+ x1="1.00000548"
+ spreadMethod="repeat"
+ id="linearGradient9646"
+ gradientUnits="objectBoundingBox" />
+ <linearGradient
+ id="linearGradient9640">
+ <stop
+ style="stop-color:#000;stop-opacity:1;"
+ offset="0"
+ id="stop9642" />
+ <stop
+ style="stop-color:#fff;stop-opacity:1;"
+ offset="1"
+ id="stop9644" />
+ </linearGradient>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ gridtolerance="10000"
+ guidetolerance="10"
+ objecttolerance="10"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.4142136"
+ inkscape:cx="536.99132"
+ inkscape:cy="529.01021"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ width="1052.3622px"
+ height="744.09448px"
+ showgrid="true"
+ inkscape:window-width="1465"
+ inkscape:window-height="896"
+ inkscape:window-x="0"
+ inkscape:window-y="25" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1">
+ <g
+ id="g5256"
+ transform="translate(631.5744,227.66157)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ transform="matrix(6.392368,0.545409,-0.130014,2.864752,-184.6606,-38.15109)"
+ style="fill:url(#radialGradient1977);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:type="arc"
+ sodipodi:ry="12.562782"
+ sodipodi:rx="12.562782"
+ sodipodi:cy="37.865574"
+ sodipodi:cx="41.875938"
+ id="path1976"
+ d="M 54.438721 37.865574 A 12.562782 12.562782 0 1 1 29.313156,37.865574 A 12.562782 12.562782 0 1 1 54.438721 37.865574 z" />
+ <g
+ transform="matrix(1,0,0,1.036969,356.8306,-11.4294)"
+ style="fill:url(#linearGradient6037);fill-opacity:1"
+ id="g4293">
+ <path
+ style="fill:url(#linearGradient5281);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2720"
+ d="M -270.85787,33.814995 C -289.35564,33.925992 -307.93321,33.592782 -326.38104,33.981747 C -331.43469,35.696391 -331.02221,41.899652 -330.68524,46.15332 C -330.75782,60.227303 -330.53537,74.298225 -330.21167,88.36826 C -328.21297,91.039611 -323.21766,90.618387 -322.68469,94.539015 C -320.78054,96.259426 -317.05071,94.88215 -314.4389,95.333237 C -298.54999,95.360274 -282.66107,95.387302 -266.77215,95.414339 C -266.35587,90.465192 -260.12609,88.824447 -255.81783,89.540255 C -256.01688,89.058389 -261.69557,87.939375 -259.61591,84.491525 C -259.45681,68.72727 -259.19734,52.882199 -259.82064,37.168229 C -261.19394,32.980583 -267.34179,33.83368 -270.85787,33.814995 z M -236.65184,97.260473 C -234.79025,100.12642 -237.08724,103.09386 -239.92892,104.16357 C -242.6311,105.91539 -245.59105,107.62992 -248.52894,108.76804 C -253.1773,108.19079 -251.42424,101.88475 -255.01281,99.896645 C -260.33594,96.447012 -267.21045,98.43943 -273.23329,97.939231 C -291.8249,97.94887 -310.41651,97.958519 -329.00813,97.968158 C -335.45898,103.56578 -339.16595,111.40269 -341.55034,119.32178 C -337.25147,124.2061 -329.89606,122.27575 -324.10438,122.40002 C -298.64553,122.23171 -273.11679,122.61546 -247.69897,122.24542 C -243.40174,121.14669 -247.44685,114.84894 -243.58488,113.04441 C -242.73865,112.73374 -247.81245,114.4382 -247.26205,111.62955 C -245.49117,106.66028 -239.14113,105.99595 -235.92338,102.36811 C -234.39131,99.755669 -236.26958,96.922488 -238.33047,95.260495 C -237.77093,95.927151 -237.21138,96.593817 -236.65184,97.260473 z M -240.64255,111.75263 C -243.64086,113.13223 -237.02792,110.69536 -235.55512,111.97369 C -229.71113,112.74417 -224.16461,117.19625 -218.12358,115.22951 C -225.97639,116.31604 -232.799,109.03014 -240.64255,111.75263 z M -212.01083,112.33724 C -215.98173,113.85021 -208.21543,112.17765 -210.07883,115.87566 C -212.50961,119.93855 -206.99008,113.8662 -209.61436,112.54677 C -210.16198,111.94632 -211.27989,112.47663 -212.01083,112.33724 z M -213.97451,120.82946 C -220.13871,124.32615 -228.37873,119.08124 -233.85995,124.39439 C -238.36465,128.00055 -244.57099,130.35185 -247.0433,135.75122 C -247.65922,139.60202 -243.25109,141.90251 -240.44565,143.71808 C -235.60127,146.54512 -228.8227,145.75388 -225.20082,141.42836 C -220.62679,137.96117 -216.44182,134.08489 -212.48592,129.96782 C -212.82701,126.95048 -214.43694,123.63971 -213.97451,120.82946 z " />
+ <path
+ style="fill:url(#linearGradient5283);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ id="path2723"
+ d="M -269.68453,32.256957 C -288.76965,32.351184 -307.87514,32.249603 -326.94796,32.349264 C -332.63884,33.663474 -333.90446,40.291305 -333.21597,45.149113 C -333.11996,59.896901 -333.07471,74.659754 -332.61729,89.39481 C -331.88583,93.310348 -324.86009,92.098674 -325.11097,96.44089 C -328.07184,96.184706 -331.5534,96.317135 -333.07248,99.246492 C -338.92562,104.98392 -341.99312,112.66465 -344.27268,120.28679 C -340.22572,125.96631 -332.26467,125.31453 -326.02946,124.71751 C -300.16629,124.7277 -274.28316,124.82043 -248.43245,124.77905 C -244.42424,124.78686 -243.30672,120.35609 -243.96666,117.2099 C -242.88598,112.93536 -237.04086,113.94554 -233.80717,114.98513 C -228.01851,116.64297 -221.26418,120.43074 -215.57982,116.37592 C -211.36091,113.71809 -213.05678,118.4029 -215.77936,119.43344 C -220.82539,122.25797 -227.09125,118.98178 -232.39677,121.20855 C -236.53238,123.88957 -240.74707,126.85249 -244.76678,129.74666 C -248.34219,132.01467 -251.90947,137.38626 -248.13747,140.97315 C -243.79274,146.02948 -236.37425,149.4527 -229.68248,147.08651 C -225.09383,144.85973 -221.79206,140.75401 -217.61535,137.88661 C -215.10454,135.69469 -212.49235,133.26839 -210.83749,130.50207 C -210.86477,126.92195 -214.68529,121.91303 -210.252,119.57013 C -207.25619,117.95208 -205.81053,112.12098 -209.75314,110.87946 C -214.16982,109.44692 -216.95156,115.09837 -221.43751,113.68608 C -228.47365,112.76758 -235.5565,107.20489 -242.69931,110.72434 C -246.89551,113.06547 -243.47174,109.4356 -241.45524,108.56544 C -237.85613,106.84628 -232.73147,104.36798 -233.94637,99.617708 C -234.27189,95.083838 -239.22223,93.197522 -242.95318,91.723135 C -247.61613,89.074942 -253.27003,89.345117 -258.06082,86.933298 C -257.89248,70.385101 -257.58805,53.76423 -258.26571,37.261116 C -259.2092,32.393288 -265.59824,31.96057 -269.68453,32.256957 z M -258.66259,91.764016 C -251.5059,92.239344 -243.21163,93.474137 -238.58238,99.271629 C -238.96251,103.06003 -244.00295,103.80224 -246.52821,106.14082 C -248.92267,108.48087 -251.12372,105.80503 -251.02958,103.27159 C -252.70852,98.336432 -258.20582,95.710815 -263.31841,96.533197 C -267.00561,96.7255 -263.71935,91.937514 -261.395,92.380192 C -260.48382,92.178338 -259.57521,91.953759 -258.66259,91.764016 z " />
+ <path
+ style="fill:url(#linearGradient5285);fill-opacity:1;stroke-width:1pt;font-family:helvetica"
+ sodipodi:nodetypes="ccccczccccccccccccccccccczccccc"
+ id="path2737"
+ d="M -324.0398,30.70877 C -336.3492,30.820231 -335.15663,39.652507 -334.79476,45.313268 C -334.5469,60.436643 -334.38614,75.599009 -334.01234,90.698281 C -333.20516,93.057424 -330.71249,93.985661 -328.75475,95.252079 C -334.4553,96.476239 -336.96996,102.43195 -340.11175,106.59303 C -342.33294,111.36531 -347.84019,115.92868 -345.92111,121.43642 C -344.00204,126.94416 -332.21757,127.68181 -324.95408,127.12866 C -299.06901,127.09789 -273.17022,127.14905 -247.29372,127.06713 C -243.29961,126.16956 -240.99668,122.03601 -241.4977,118.23645 C -238.30082,114.95371 -233.32521,118.03039 -229.53292,118.63002 C -225.71641,119.31313 -232.5646,119.27527 -233.19362,120.54849 C -238.23604,122.95799 -242.6166,126.65447 -246.90973,130.10509 C -250.44674,132.97354 -252.4229,138.10741 -249.57412,142.08235 C -246.21315,145.92284 -241.41489,148.84284 -236.30395,149.79628 C -230.65487,150.83779 -225.57101,147.82678 -221.6157,144.24077 C -216.87391,140.59839 -212.0873,136.78287 -208.84361,131.80554 C -207.76302,128.26399 -211.47449,123.86671 -208.08348,121.09796 C -204.93438,118.46115 -204.06893,113.02076 -207.41836,110.2673 C -212.81988,106.81278 -218.36682,114.55112 -223.89705,111.29128 C -227.94209,110.1659 -231.91311,108.52596 -236.17676,108.45194 C -231.52711,105.88023 -229.62903,98.782331 -234.08944,95.153402 C -239.61551,89.404431 -248.455,88.793917 -255.40182,85.744487 C -255.86992,78.940296 -255.53665,71.972758 -255.70928,65.098797 C -255.80747,55.730822 -255.73864,46.312632 -255.94025,36.975777 C -258.03631,31.236293 -265.34014,30.439522 -270.76286,30.729689 C -289.40725,30.770714 -311.88665,30.597309 -324.0398,30.70877 z M -255.46516,94.482857 C -250.34561,95.62106 -244.69322,96.21649 -240.83258,100.05203 C -242.37635,102.55028 -245.27573,103.64481 -247.80048,104.97505 C -249.71506,99.684643 -254.39847,94.970039 -260.51378,95.138259 C -260.66903,94.131274 -256.73261,94.551178 -255.46516,94.482857 z " />
+ </g>
+ <rect
+ y="78.658051"
+ x="33.326111"
+ width="57.567924"
+ style="fill:url(#linearGradient1156);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1157);stroke-width:1.44734821pt"
+ id="rect1155"
+ height="8.3153667" />
+ <path
+ style="fill:url(#linearGradient1169);fill-rule:evenodd;stroke-width:0.90459263;stroke-opacity:0.07438019"
+ sodipodi:nodetypes="czzczczzzzzzzc"
+ id="path2676"
+ d="M 98.723806,78.927818 C 95.18666,77.759681 93.50122,82.555591 98.766686,81.004087 C 104.03217,79.452583 120.13123,85.906451 120.37383,89.795491 C 120.61643,93.905503 101.5003,98.581154 106.74108,104.42426 C 111.62816,110.70149 115.35468,100.13868 123.54696,104.21261 C 131.73923,108.17607 136.26048,109.72394 142.25488,104.94185 C 149.10027,101.9342 145.04599,107.07658 139.57918,113.60451 C 134.11237,120.13244 144.00251,115.08156 147.91225,105.31962 C 151.93248,95.557673 139.13128,107.33503 133.66268,105.40571 C 128.19408,103.47639 119.73678,97.849788 113.27625,102.55563 C 106.81572,107.26147 109.62894,99.493003 114.85637,97.90307 C 120.0838,96.092166 122.81363,93.045722 122.85597,90.161522 C 122.89831,87.498293 117.92629,84.811803 112.94229,82.402852 C 107.73732,79.993901 100.49788,78.588966 98.723806,78.927818 z " />
+ <path
+ style="fill:url(#linearGradient1140);fill-opacity:1;fill-rule:evenodd;stroke-width:1.44734821pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1139"
+ d="M 15.102732,106.80712 C 13.80355,109.23224 17.148847,113.52338 19.900059,113.52338 L 107.85106,113.52338 C 110.18914,113.52338 113.70766,110.4906 112.64839,108.40622 L 102.7339,88.897093 C 101.97024,87.394398 100.26184,86.65834 98.576216,86.65834 L 28.215425,86.658339 C 26.825434,86.658339 25.353768,87.671846 24.697385,88.897093 L 15.102732,106.80712 z " />
+ <rect
+ y="22.413721"
+ x="26.015469"
+ width="72.279724"
+ style="fill:url(#linearGradient905);fill-opacity:1;fill-rule:evenodd;stroke-width:1.62826681"
+ ry="5.4369707"
+ rx="5.4369707"
+ id="rect1137"
+ height="60.126495" />
+ <rect
+ y="31.695871"
+ x="33.386066"
+ width="58.178177"
+ style="fill:url(#radialGradient1132);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient891);stroke-width:1.4649456pt"
+ id="rect1131"
+ height="38.044163" />
+ <path
+ style="fill:url(#linearGradient1146);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccccc"
+ id="path1145"
+ d="M 27.690431,52.841444 L 27.370609,74.749236 C 27.319624,78.241665 29.310209,80.477938 32.807578,80.506029 L 72.625393,80.825852 L 76.463254,71.87084 L 32.008024,71.55102 L 31.688202,52.681533 L 27.690431,52.841444 z " />
+ <g
+ transform="matrix(-1,0,0,1,125.4301,0)"
+ id="g1791">
+ <path
+ style="fill:url(#linearGradient1148);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1147"
+ d="M 42.062098,33.460351 L 77.341205,33.008055 C 82.787126,32.938235 89.553204,38.416797 89.553204,43.863165 L 89.553204,60.14583 L 41.609801,59.693534 L 42.062098,33.460351 z " />
+ <path
+ style="fill:url(#linearGradient1150);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzccc"
+ id="path1149"
+ d="M 78.337784,67.629235 L 46.723745,67.724544 C 41.843589,67.739257 35.829319,62.771024 35.877168,57.891081 L 36.020221,43.301821 L 78.973514,44.128288 L 78.337784,67.629235 z " />
+ </g>
+ <path
+ style="fill:url(#linearGradient1167);fill-opacity:1;fill-rule:evenodd;stroke-width:0.72367412;stroke-opacity:0.34710741"
+ sodipodi:nodetypes="cczzzzzzc"
+ id="path1159"
+ d="M 137.39107,112.02341 C 137.39107,112.02341 129.0757,110.26438 123.63872,113.62251 C 118.20176,116.98064 109.96635,123.21719 108.76702,124.81628 C 107.40777,126.57531 107.42036,130.22796 109.24674,131.53253 L 114.84364,135.53031 C 118.31797,138.01198 124.86218,139.25396 128.11624,136.48978 L 142.98795,123.85681 C 144.79792,122.3193 145.72732,118.27921 144.10733,116.82073 C 142.95609,115.04975 140.4892,112.91939 137.39107,112.02341 z " />
+ <path
+ style="fill:url(#linearGradient1171);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzc"
+ id="path1160"
+ d="M 142.3483,121.13833 L 125.91043,133.59673 C 122.97154,135.82414 118.65484,134.11775 116.28283,133.77129 C 113.9108,133.42481 111.88528,131.87901 112.12516,132.33209 C 112.36503,132.78517 115.08349,135.71687 117.72203,136.48978 C 120.36055,137.26267 124.9543,138.89307 127.50953,136.15531 C 130.06477,133.41755 145.2267,123.53699 142.3483,121.13833 z " />
+ <path
+ style="fill:url(#linearGradient1404);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="cczc"
+ id="path1403"
+ d="M 132.11225,127.51984 C 135.31047,122.88242 120.11893,113.12786 109.08509,127.0401 C 110.20446,130.71805 116.80662,132.5992 121.82304,132.33547 C 126.68363,132.07993 129.50037,129.97181 132.11225,127.51984 z " />
+ <path
+ style="fill:url(#linearGradient1166);fill-opacity:1;fill-rule:evenodd;stroke-width:1.08551121"
+ sodipodi:nodetypes="cccccccc"
+ id="path1519"
+ d="M 138.63464,112.68306 C 135.9958,113.22749 132.31739,114.43079 129.87534,116.38362 C 128.77009,115.68011 125.32759,114.5677 123.66767,113.84494 L 123.24572,114.10517 C 129.67287,117.23476 136.43512,117.91249 135.88192,122.87668 C 136.33675,122.98575 137.05589,123.09702 136.73191,122.38863 C 136.41775,118.90392 132.50587,117.23351 131.02697,116.81532 C 133.17224,114.26602 136.255,113.70892 138.63464,112.68306 z " />
+ <path
+ style="fill:url(#linearGradient1144);fill-opacity:1;fill-rule:evenodd;stroke-width:1pt"
+ sodipodi:nodetypes="czzzzzzzz"
+ id="path1143"
+ d="M 18.891612,106.48414 C 17.978451,108.31614 19.173914,111.55774 22.263529,111.55774 L 105.0195,111.55774 C 106.66288,111.55774 109.13595,109.26672 108.39142,107.69215 L 101.42279,92.954575 C 100.88602,91.819403 99.685232,91.263378 98.500462,91.263378 L 28.108183,91.263369 C 27.131195,91.263369 26.0968,92.028994 25.635445,92.954575 L 18.891612,106.48414 z " />
+ <text
+ y="-14.660837"
+ xml:space="preserve"
+ x="6.147172"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1232"><tspan
+ id="tspan1233">Computer</tspan></text>
+ <text
+ y="-34.951134"
+ xml:space="preserve"
+ x="84.564949"
+ transform="scale(0.246729,0.246729)"
+ style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:helvetica"
+ id="text1235"><tspan
+ id="tspan1236">Created by Andrew Fitzsimon</tspan></text>
+ </g>
+ <g
+ id="g5474"
+ transform="translate(633.63525,501.49239)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157">
+ <path
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path9383"
+ d="M 203.47051,-209.74941 C 198.72111,-204.56585 195.69876,-195.27863 189.00642,-195.27863 C 182.52997,-197.07848 181.66644,-212.48518 180.80291,-215.7969 C 188.1429,-210.75732 195.69876,-207.87757 203.47051,-209.74941 z " />
+ <path
+ transform="matrix(-0.440859,0,0,0.441062,265.52775,-266.17138)"
+ style="fill:#f1bb96;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:type="arc"
+ sodipodi:ry="57.825485"
+ sodipodi:rx="60.94183"
+ sodipodi:cy="70.290855"
+ sodipodi:cx="150.27701"
+ id="path3713"
+ d="M 211.21884 70.290855 A 60.94183 57.825485 0 1 1 89.335178,70.290855 A 60.94183 57.825485 0 1 1 211.21884 70.290855 z" />
+ <path
+ style="fill:#233e6a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccssssc"
+ id="path4369"
+ d="M 232.46888,-182.94274 C 232.85952,-157.74648 168.23012,-154.86512 168.38642,-182.94274 C 166.84164,-205.27149 177.94687,-217.96719 180.70654,-215.80872 C 182.10778,-214.71274 182.62841,-190.37295 192.09635,-195.9716 C 196.69923,-198.69339 201.84768,-209.14846 204.10029,-209.49532 C 207.49937,-210.01873 214.00811,-212.77083 219.98583,-217.92153 C 221.55412,-219.27285 231.93943,-205.38255 232.46888,-182.94274 z " />
+ <path
+ style="fill:#513624;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path11309"
+ d="M 204.55432,-273.85152 C 222.46413,-271.53047 237.32676,-259.28175 231.38357,-231.42099 C 229.66954,-221.67743 222.12426,-217.60887 219.35537,-236.36962 C 211.4578,-233.88387 177.25785,-223.92576 170.54948,-241.26677 C 166.55631,-248.43407 174.86257,-276.23329 204.55432,-273.85152 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path11942"
+ d="M 191.92173,-167.75448 C 192.06919,-184.44566 194.18855,-193.73288 188.47558,-194.95709 C 182.9785,-195.85052 179.91138,-176.52634 179.04785,-173.21462 C 175.85958,-157.19769 189.53653,-154.44605 191.92173,-167.75448 z " />
+ <path
+ style="fill:url(#linearGradient1815);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:8.50416374;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1811"
+ d="M 172.67812,-237.76056 C 182.56217,-225.58826 212.09549,-234.15979 219.36562,-236.44806 C 220.33459,-229.88278 221.90014,-226.25074 223.58437,-224.54181 C 219.31219,-215.8234 210.06249,-209.76056 199.27187,-209.76056 C 184.44142,-209.76056 172.42812,-221.18201 172.42812,-235.26056 C 172.42812,-236.11869 172.59078,-236.92413 172.67812,-237.76056 z " />
+ <path
+ style="fill:url(#radialGradient1818);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1817"
+ d="M 203.17522,-273.74212 C 221.08504,-271.42107 235.94766,-259.17235 230.00448,-231.31159 C 228.29044,-221.56803 220.74517,-217.49946 217.97627,-236.26022 C 210.0787,-233.77447 175.87876,-223.81635 169.17039,-241.15737 C 165.17722,-248.32467 173.48348,-276.12389 203.17522,-273.74212 z " />
+ <path
+ style="fill:url(#radialGradient1822);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ id="path1819"
+ d="M 220.74123,-214.1875 C 227.87764,-203.73841 231.28831,-190.18836 229.45998,-177.71875 C 222.3997,-165.39834 205.93726,-163.52328 193.05373,-164.75 C 194.11526,-173.29796 194.69425,-182.39807 193.51876,-190.98978 C 191.02311,-195.41909 199.33209,-197.29913 200.39748,-201.6875 C 203.70655,-208.92744 212.80427,-208.10966 218.04988,-213.3696 C 218.9201,-213.57294 220.00051,-215.94141 220.74123,-214.1875 z M 179.55373,-210.28125 C 180.69974,-204.97453 181.23339,-199.24919 184.58498,-194.75 C 179.40159,-187.81847 178.05976,-178.63643 176.67873,-170.28125 C 167.10271,-177.01707 169.81568,-190.62142 172.02963,-200.39411 C 173.03008,-204.26346 176.36728,-212.34166 179.19382,-211.77772 C 179.27177,-211.45363 179.5117,-210.45598 179.55373,-210.28125 z " />
+ <path
+ style="fill:url(#radialGradient1824);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="cccc"
+ id="path1823"
+ d="M 192.35803,-167.43887 C 192.50549,-184.13006 194.62485,-193.41727 188.91188,-194.64149 C 183.4148,-195.53491 180.34768,-176.21073 179.48415,-172.89901 C 176.29589,-156.88208 189.97283,-154.13044 192.35803,-167.43887 z " />
+ <path
+ style="fill:#1f4eb3;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1825"
+ d="M 185.2414,-200.53324 C 185.2414,-197.95291 187.25802,-195.85872 189.74278,-195.85872 C 192.22755,-195.85872 194.24417,-197.95291 194.24417,-200.53324 C 194.24417,-203.11357 193.61259,-209.36288 191.12783,-209.36288 C 188.64306,-209.36288 185.2414,-203.11357 185.2414,-200.53324 z " />
+ <path
+ style="fill:url(#radialGradient1828);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3.75;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1"
+ sodipodi:nodetypes="ccccc"
+ id="path1827"
+ d="M 186.28018,-201.05263 C 186.28018,-198.4723 188.2968,-196.37811 190.78156,-196.37811 C 193.26633,-196.37811 195.28295,-198.4723 195.28295,-201.05263 C 195.28295,-203.63296 194.65137,-209.88227 192.16661,-209.88227 C 189.68184,-209.88227 186.28018,-203.63296 186.28018,-201.05263 z " />
+ </g>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="345.5625"
+ y="218.05542"
+ id="text7877"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ x="345.5625"
+ y="218.05542"
+ id="tspan2399">create project</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9548"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,24.174103)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.53906"
+ y="217.78979"
+ id="text9550"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9552"
+ x="314.53906"
+ y="217.78979">1</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9554"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(33.388397,76.658478)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="315.78125"
+ y="270.48511"
+ id="text9556"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9558"
+ x="315.78125"
+ y="270.48511">2</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="344.92188"
+ y="267.43823"
+ id="text9566"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9568"
+ x="344.92188"
+ y="267.43823">record changes</tspan></text>
+ <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path9652"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,128.5416)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.88281"
+ y="322.14166"
+ id="text9654"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9656"
+ x="314.88281"
+ y="322.14166">3</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="346.9086"
+ y="319.32135"
+ id="text9658"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan9660"
+ x="346.9086"
+ y="319.32135">browse history</tspan></text>
+ <flowRoot
+ xml:space="preserve"
+ id="flowRoot2405"><flowRegion
+ id="flowRegion2407"><rect
+ id="rect2409"
+ width="274.35742"
+ height="94.045197"
+ x="293.44931"
+ y="485.2934" /></flowRegion><flowPara
+ id="flowPara2411"></flowPara></flowRoot> <path
+ sodipodi:type="arc"
+ style="fill:#000000"
+ id="path2427"
+ sodipodi:cx="292.14285"
+ sodipodi:cy="181.95163"
+ sodipodi:rx="15"
+ sodipodi:ry="15"
+ d="M 307.14285 181.95163 A 15 15 0 1 1 277.14285,181.95163 A 15 15 0 1 1 307.14285 181.95163 z"
+ transform="translate(32.857147,180.5416)"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157" />
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="314.9375"
+ y="374.15729"
+ id="text2429"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2431"
+ x="314.9375"
+ y="374.15729">4</tspan></text>
+ <text
+ xml:space="preserve"
+ style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:aquafont"
+ x="346.9086"
+ y="371.32135"
+ id="text2433"
+ sodipodi:linespacing="125%"
+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_single.png"
+ inkscape:export-xdpi="41.964157"
+ inkscape:export-ydpi="41.964157"><tspan
+ sodipodi:role="line"
+ id="tspan2435"
+ x="346.9086"
+ y="371.32135">package release</tspan></text>
+ </g>
+</svg>
diff --git a/doc/ru/user-guide/index-plain.txt b/doc/ru/user-guide/index-plain.txt
new file mode 100644
index 0000000..315b30d
--- /dev/null
+++ b/doc/ru/user-guide/index-plain.txt
@@ -0,0 +1,121 @@
+###############################
+Руководство пользователя Bazaar
+###############################
+
+.. Пожалуйста отмечайте секции в подключаемых файлах следующим образом:
+.. уровень 1 ========
+.. уровень 2 --------
+.. уровень 3 ~~~~~~~~
+.. уровень 4 ^^^^^^^^ (лучше не использовать вложенность больше 3-х уровней)
+
+.. contents::
+ Содержание
+ :depth: 2
+.. sectnum::
+
+
+Введение
+########
+
+.. include:: introducing_bazaar.txt
+.. include:: core_concepts.txt
+.. include:: ../../en/user-guide/bazaar_workflows.txt
+
+
+Начинаем работать
+#################
+
+.. include:: ../../en/user-guide/installing_bazaar.txt
+.. include:: ../../en/user-guide/entering_commands.txt
+.. include:: ../../en/user-guide/getting_help.txt
+.. include:: ../../en/user-guide/configuring_bazaar.txt
+.. include:: ../../en/user-guide/using_aliases.txt
+.. include:: ../../en/user-guide/plugins.txt
+.. include:: zen.txt
+
+
+Личный контроль версий
+######################
+
+.. include:: ../../en/user-guide/solo_intro.txt
+.. include:: ../../en/user-guide/starting_a_project.txt
+.. include:: ../../en/user-guide/controlling_registration.txt
+.. include:: ../../en/user-guide/reviewing_changes.txt
+.. include:: ../../en/user-guide/recording_changes.txt
+.. include:: ../../en/user-guide/browsing_history.txt
+.. include:: ../../en/user-guide/releasing_a_project.txt
+.. include:: ../../en/user-guide/undoing_mistakes.txt
+
+
+Делимся с другими
+#################
+
+.. include:: ../../en/user-guide/partner_intro.txt
+.. include:: branching_a_project.txt
+.. include:: ../../en/user-guide/merging_changes.txt
+.. include:: ../../en/user-guide/resolving_conflicts.txt
+.. include:: ../../en/user-guide/annotating_changes.txt
+
+
+Сотрудничество в команде, централизованный стиль
+################################################
+
+.. include:: ../../en/user-guide/central_intro.txt
+.. include:: ../../en/user-guide/publishing_a_branch.txt
+.. include:: using_checkouts.txt
+.. include:: ../../en/user-guide/working_offline_central.txt
+.. include:: ../../en/user-guide/reusing_a_checkout.txt
+
+
+Сотрудничество в команде, распределенный стиль
+##############################################
+
+.. include:: ../../en/user-guide/distributed_intro.txt
+.. include:: ../../en/user-guide/organizing_branches.txt
+.. include:: ../../en/user-guide/using_gatekeepers.txt
+.. include:: ../../en/user-guide/sending_changes.txt
+
+
+Различные темы
+##############
+
+.. include:: ../../en/user-guide/part2_intro.txt
+.. include:: ../../en/user-guide/adv_merging.txt
+.. include:: ../../en/user-guide/shelving_changes.txt
+.. include:: ../../en/user-guide/filtered_views.txt
+.. include:: stacked.txt
+.. include:: ../../en/user-guide/server.txt
+.. include:: ../../en/user-guide/hooks.txt
+.. include:: ../../en/user-guide/version_info.txt
+
+
+Краткое описание некоторых популярных плагинов
+##############################################
+
+.. include:: ../../en/user-guide/bzrtools_plugin.txt
+.. include:: ../../en/user-guide/svn_plugin.txt
+.. include later looms_plugin.txt
+
+
+Интегрируем Bazaar в нашу среду
+###############################
+
+.. include:: ../../en/user-guide/web_browsing.txt
+.. include later - file_explorers.txt
+.. include later - desktop_integration.txt
+.. include later - editors_and_ides.txt
+.. include later - email.txt
+.. include:: ../../en/user-guide/bug_trackers.txt
+
+
+Приложения
+##########
+
+.. include:: specifying_revisions.txt
+.. include:: ../../en/user-guide/organizing_your_workspace.txt
+.. include:: ../../en/user-guide/shared_repository_layouts.txt
+.. include:: ../../en/user-guide/setting_up_email.txt
+.. include:: ../../en/user-guide/http_smart_server.txt
+.. include:: ../../en/user-guide/writing_a_plugin.txt
+
+.. |--| unicode:: U+2014
diff --git a/doc/ru/user-guide/index.txt b/doc/ru/user-guide/index.txt
new file mode 100644
index 0000000..315b30d
--- /dev/null
+++ b/doc/ru/user-guide/index.txt
@@ -0,0 +1,121 @@
+###############################
+Руководство пользователя Bazaar
+###############################
+
+.. Пожалуйста отмечайте секции в подключаемых файлах следующим образом:
+.. уровень 1 ========
+.. уровень 2 --------
+.. уровень 3 ~~~~~~~~
+.. уровень 4 ^^^^^^^^ (лучше не использовать вложенность больше 3-х уровней)
+
+.. contents::
+ Содержание
+ :depth: 2
+.. sectnum::
+
+
+Введение
+########
+
+.. include:: introducing_bazaar.txt
+.. include:: core_concepts.txt
+.. include:: ../../en/user-guide/bazaar_workflows.txt
+
+
+Начинаем работать
+#################
+
+.. include:: ../../en/user-guide/installing_bazaar.txt
+.. include:: ../../en/user-guide/entering_commands.txt
+.. include:: ../../en/user-guide/getting_help.txt
+.. include:: ../../en/user-guide/configuring_bazaar.txt
+.. include:: ../../en/user-guide/using_aliases.txt
+.. include:: ../../en/user-guide/plugins.txt
+.. include:: zen.txt
+
+
+Личный контроль версий
+######################
+
+.. include:: ../../en/user-guide/solo_intro.txt
+.. include:: ../../en/user-guide/starting_a_project.txt
+.. include:: ../../en/user-guide/controlling_registration.txt
+.. include:: ../../en/user-guide/reviewing_changes.txt
+.. include:: ../../en/user-guide/recording_changes.txt
+.. include:: ../../en/user-guide/browsing_history.txt
+.. include:: ../../en/user-guide/releasing_a_project.txt
+.. include:: ../../en/user-guide/undoing_mistakes.txt
+
+
+Делимся с другими
+#################
+
+.. include:: ../../en/user-guide/partner_intro.txt
+.. include:: branching_a_project.txt
+.. include:: ../../en/user-guide/merging_changes.txt
+.. include:: ../../en/user-guide/resolving_conflicts.txt
+.. include:: ../../en/user-guide/annotating_changes.txt
+
+
+Сотрудничество в команде, централизованный стиль
+################################################
+
+.. include:: ../../en/user-guide/central_intro.txt
+.. include:: ../../en/user-guide/publishing_a_branch.txt
+.. include:: using_checkouts.txt
+.. include:: ../../en/user-guide/working_offline_central.txt
+.. include:: ../../en/user-guide/reusing_a_checkout.txt
+
+
+Сотрудничество в команде, распределенный стиль
+##############################################
+
+.. include:: ../../en/user-guide/distributed_intro.txt
+.. include:: ../../en/user-guide/organizing_branches.txt
+.. include:: ../../en/user-guide/using_gatekeepers.txt
+.. include:: ../../en/user-guide/sending_changes.txt
+
+
+Различные темы
+##############
+
+.. include:: ../../en/user-guide/part2_intro.txt
+.. include:: ../../en/user-guide/adv_merging.txt
+.. include:: ../../en/user-guide/shelving_changes.txt
+.. include:: ../../en/user-guide/filtered_views.txt
+.. include:: stacked.txt
+.. include:: ../../en/user-guide/server.txt
+.. include:: ../../en/user-guide/hooks.txt
+.. include:: ../../en/user-guide/version_info.txt
+
+
+Краткое описание некоторых популярных плагинов
+##############################################
+
+.. include:: ../../en/user-guide/bzrtools_plugin.txt
+.. include:: ../../en/user-guide/svn_plugin.txt
+.. include later looms_plugin.txt
+
+
+Интегрируем Bazaar в нашу среду
+###############################
+
+.. include:: ../../en/user-guide/web_browsing.txt
+.. include later - file_explorers.txt
+.. include later - desktop_integration.txt
+.. include later - editors_and_ides.txt
+.. include later - email.txt
+.. include:: ../../en/user-guide/bug_trackers.txt
+
+
+Приложения
+##########
+
+.. include:: specifying_revisions.txt
+.. include:: ../../en/user-guide/organizing_your_workspace.txt
+.. include:: ../../en/user-guide/shared_repository_layouts.txt
+.. include:: ../../en/user-guide/setting_up_email.txt
+.. include:: ../../en/user-guide/http_smart_server.txt
+.. include:: ../../en/user-guide/writing_a_plugin.txt
+
+.. |--| unicode:: U+2014
diff --git a/doc/ru/user-guide/introducing_bazaar.txt b/doc/ru/user-guide/introducing_bazaar.txt
new file mode 100644
index 0000000..05d230a
--- /dev/null
+++ b/doc/ru/user-guide/introducing_bazaar.txt
@@ -0,0 +1,150 @@
+Представляем Bazaar
+===================
+
+Что такое Bazaar?
+-----------------
+
+Bazaar - это инструмент помогающий людям сотрудничать. Он отслеживает
+изменения, которые вы и другие люди делают с группой файлов, (таких как
+исходный код программы) для того что бы дать вам снимок каждого этапа их
+эволюции. Используя эту информацию, Bazaar может без проблем объединить вашу
+работу с работой других людей.
+
+Такие инструменты как Bazaar называются системами контроля версий (Version
+Control System (VCS)) и уже долгое время популярны среди разработчиков ПО.
+Легкость использования, гибкость и простота настройки Bazaar делают его
+идеальным не только для разработчиков ПО, но так же и для других групп,
+работающих совместно с файлами и документами, таких как технические писатели,
+Web-дизайнеры и переводчики.
+
+Это руководство описывает установку и использование Bazaar вне зависимости от
+того работает вы один, или в команде с другими людьми. Если вы уже знаете, что
+такое распределенная система контроля версий и хотите перейти прямо к описанию
+работы вы можете бегло просмотреть эту секцию и перейти прямо к
+`Продолжаем изучение`_.
+
+Краткая история систем контроля версий
+--------------------------------------
+
+Инструменты для контроля версий на данный момент развиваются уже в течение
+нескольких десятилетий. Простыми словами можно описать 4 поколения таких
+инструментов:
+
+ 1. инструменты контроля версий файлов, например CSSC, RCS
+ 2. инструменты контроля дерева файлов - централизованный стиль, например CVS
+ 3. инструменты контроля дерева файлов - централизованный стиль, этап 2,
+ например Subversion
+ 4. инструменты контроля дерева файлов - распределенный стиль, например Bazaar.
+
+Дизайн и реализация Bazaar учитывает уроки полученные на каждом из этих этапов
+развития подобных инструментов. В частности, Bazaar аккуратно поддерживает и
+централизованную и распределенную модели контроля версий и таким образом вы
+можете менять модель работы (когда это имеет смысл) без необходимости смены
+инструмента.
+
+Централизованная модель против распределенной
+---------------------------------------------
+
+Многие традиционные инструменты контроля версий требуют наличия центрального
+сервера, который хранит историю изменений (или *репозиторий*) для дерева
+файлов. Что бы работать с файлами пользователю необходимо установить соединение
+с сервером и получить *рабочую версию* файлов. Таким образом пользователь
+получает *рабочее дерево* в котором он может работать. Для сохранения, или
+*фиксации* изменений пользователю нужен доступ к центральному серверу и он
+должен убедиться, что перед фиксацией он объединил свою работу с последней
+версией сохраненной на сервере. Такой подход известен как централизованная
+модель.
+
+Централизованная модель проверена достаточно долгой практикой, но она имеет и
+некоторые значительные недостатки. Во-первых, централизованная система требует
+наличия соединения с сервером при выполнении большинства операций по контролю
+версий. Во-вторых, централизованная модель жестко связывает момент **фиксации**
+изменений с моментом их **публикации**. В каких-то ситуациях это может быть
+нормально, но может сказываться негативно в других.
+
+Распределенные системы контроля версий позволяют отдельным пользователям и
+командам иметь несколько репозиториев, вместо одного центрального. В случае с
+Bazaar история обычно хранится в том же месте, что и код который находится под
+контролем версий. Это позволяет пользователю фиксировать свои изменения в любой
+момент когда это нужно, даже при отсутствии сетевого соединения. Сетевое
+соединение требуется только для публикации изменений, или когда нужен доступ к
+изменениям в другом месте.
+
+На самом деле для разработчиков использование распределенных систем контроля
+версий может иметь другие преимущества, кроме очевидных, связанных с работой
+при отсутствии сетевого соединения. Другие преимущества включают:
+
+ * более легкое создание разработчиками экспериментальных веток
+ * более легкое сотрудничество с другими разработчикам
+ * меньше времени требуется для механических задач и больше для творчества
+
+ * увеличение гибкости в управлении релизами через использование
+ фиксаций включающих набор изменений для конкретной функциональности
+
+ * качество и стабильность основной ветки может быть выше, что делает
+ работу проще для каждого
+
+ * для сообществ с открытым исходным кодом:
+
+ * более легкое создание и поддержка изменений для сторонних разработчиков
+
+ * упрощение взаимодействия основных разработчиков со сторонними
+ разработчиками и более простая миграция сторонних разработчиков в основные
+
+ * для компаний - упрощение работы с распределенными и внешними командами.
+
+Для более детального взгляда на преимущества распределенных систем контроля
+версий по сравнению с централизованными смотрите http://wiki.bazaar.canonical.com/BzrWhy.
+
+
+Ключевые особенности Bazaar
+---------------------------
+
+Хотя Bazaar не единственная распределенная система контроля версий, она имеет
+некоторые значимые преимущества, которые делают ее прекрасным выбором для
+многих команд и сообществ. Описание этих особенностей и сравнение с другими
+системами контроля версий может быть найдено на Wiki Bazaar -
+http://wiki.bazaar.canonical.com.
+
+Из большинства особенностей, одна требует особого упоминания: Bazaar - это
+полностью свободное ПО написанное на языке Python. Это упрощает сотрудничество
+для внесения улучшений. Если вы хотите помочь, обратите внимание на
+http://wiki.bazaar.canonical.com/BzrSupport.
+
+
+Продолжаем изучение
+-------------------
+
+Это руководство представляет из себя легкое для чтения введение в Bazaar и
+описание его использования. Всем пользователям рекомендуется прочесть хотя бы
+окончание этой главы, так как:
+
+ * она описывает основные концепции, которые нужно знать пользователям
+ * она описывает некоторые популярные пути использования Bazaar для
+ сотрудничества.
+
+Главы 2-6 более детально описывают использование Bazaar для выполнения
+различных задач. Большинству пользователей рекомендуется прочесть их одну за
+другой сразу после начала использования Bazaar. Глава 7 и дальше содержат
+дополнительную информацию, которая поможет получить максимум от Bazaar после
+того как понятны основные функции. Этот материал может быть прочитан когда
+потребуется и в любом порядке.
+
+Если вы уже хорошо знакомы с другими системами контроля версий, вы возможно
+захотите вникнуть скорее через чтение следующих документов:
+
+ * `Bazaar за пять минут`_ - небольшое введение
+
+ * `Bazaar. Карточка быстрого старта`_ - наиболее часто используемые команды на
+ одной странице.
+
+Плюс к этому справка на сайте и `Справка по Bazaar`_ предоставляют все детали
+по доступным командам и опциям.
+
+.. _Bazaar за пять минут: ../mini-tutorial/index.html
+.. _Bazaar. Карточка быстрого старта: ../quick-reference/quick-start-summary.svg
+.. _Справка по Bazaar: ../../en/user-reference/bzr_man.html
+
+Мы надеемся, что вам понравится это руководство. Если у вас есть пожелания по
+улучшению документации Bazaar вы можете написать в список рассылки
+bazaar@lists.canonical.com.
diff --git a/doc/ru/user-guide/specifying_revisions.txt b/doc/ru/user-guide/specifying_revisions.txt
new file mode 100644
index 0000000..0d2936b
--- /dev/null
+++ b/doc/ru/user-guide/specifying_revisions.txt
@@ -0,0 +1,153 @@
+Определение ревизий
+===================
+
+Revision identifiers and ranges
+-------------------------------
+
+Bazaar has a very expressive way to specify a revision or a range of revisions.
+To specify a range of revisions, the upper and lower bounds are separated by the
+``..`` symbol. For example::
+
+ $ bzr log -r 1..4
+
+You can omit one bound like::
+
+ $ bzr log -r 1..
+ $ bzr log -r ..4
+
+Some commands take only one revision, not a range. For example::
+
+ $ bzr cat -r 42 foo.c
+
+In other cases, a range is required but you want the length of the range to
+be one. For commands where this is relevant, the ``-c`` option is used like this::
+
+ $ bzr diff -c 42
+
+
+Available revision identifiers
+------------------------------
+
+The revision, or the bounds of the range, can be given using
+different format specifications as shown below.
+
+ +----------------------+------------------------------------+
+ | argument type | description |
+ +----------------------+------------------------------------+
+ | *number* | revision number |
+ +----------------------+------------------------------------+
+ | **revno**:*number* | positive revision number |
+ +----------------------+------------------------------------+
+ | **last**:*number* | negative revision number |
+ +----------------------+------------------------------------+
+ | **revid**:*guid* | globally unique revision id |
+ +----------------------+------------------------------------+
+ | **before**:*rev* | leftmost parent of ''rev'' |
+ +----------------------+------------------------------------+
+ | **date**:*value* | first entry after a given date |
+ +----------------------+------------------------------------+
+ | **tag**:*value* | revision matching a given tag |
+ +----------------------+------------------------------------+
+ | **ancestor**:*path* | last merged revision from a branch |
+ +----------------------+------------------------------------+
+ | **branch**:*path* | latest revision on another branch |
+ +----------------------+------------------------------------+
+ | **submit**:*path* | common ancestor with submit branch |
+ +----------------------+------------------------------------+
+
+A brief introduction to some of these formats is given below.
+For complete details, see `Revision Identifiers`_ in the
+Bazaar User Reference.
+
+.. _Revision Identifiers: ../user-reference/bzr_man.html#revision-identifiers
+
+Numbers
+~~~~~~~
+
+Positive numbers denote revision numbers in the current branch. Revision
+numbers are labelled as "revno" in the output of ``bzr log``. To display
+the log for the first ten revisions::
+
+ $ bzr log -r ..10
+
+Negative numbers count from the latest revision, -1 is the last committed
+revision.
+
+To display the log for the last ten revisions::
+
+ $ bzr log -r -10..
+
+revid
+~~~~~
+
+**revid** allows specifying a an internal revision ID, as shown by ``bzr
+log`` and some other commands.
+
+For example::
+
+ $ bzr log -r revid:Matthieu.Moy@imag.fr-20051026185030-93c7cad63ee570df
+
+before
+~~~~~~
+
+**before**
+ ''rev'' specifies the leftmost parent of ''rev'', that is the revision
+ that appears before ''rev'' in the revision history, or the revision that
+ was current when ''rev'' was committed.
+
+''rev'' can be any revision specifier and may be chained.
+
+For example::
+
+ $ bzr log -r before:before:4
+ ...
+ revno: 2
+ ...
+
+date
+~~~~
+
+**date**
+ ''value'' matches the first history entry after a given date, either at
+ midnight or at a specified time.
+
+Legal values are:
+
+ * **yesterday**
+ * **today**
+ * **tomorrow**
+ * A **YYYY-MM-DD** format date.
+ * A **YYYY-MM-DD,HH:MM:SS** format date/time, seconds are optional (note the
+ comma)
+
+The proper way of saying "give me all the log entries for today" is::
+
+ $ bzr log -r date:yesterday..date:today
+
+Ancestor
+~~~~~~~~
+
+**ancestor**:*path*
+ specifies the common ancestor between the current branch and a
+ different branch. This is the same ancestor that would be used for
+ merging purposes.
+
+*path* may be the URL of a remote branch, or the file path to a local branch.
+
+For example, to see what changes were made on a branch since it was forked
+off ``../parent``::
+
+ $ bzr diff -r ancestor:../parent
+
+Branch
+~~~~~~
+
+branch
+ ``path`` specifies the latest revision in another branch.
+
+``path`` may be the URL of a remote branch, or the file path to a local branch.
+
+For example, to get the differences between this and another branch::
+
+ $ bzr diff -r branch:http://example.com/bzr/foo.dev
+
diff --git a/doc/ru/user-guide/stacked.txt b/doc/ru/user-guide/stacked.txt
new file mode 100644
index 0000000..4c9ee79
--- /dev/null
+++ b/doc/ru/user-guide/stacked.txt
@@ -0,0 +1,84 @@
+.. _using-stacked-branches:
+
+Использование стека веток
+=========================
+
+Что такое ветка в стеке?
+------------------------
+
+Ветка в стеке - это ветка которая знает как найти ревизии в другой ветке. Ветка
+в стеке хранит только уникальные ревизии, которые при этом быстрее создавать и
+они более эффективны по занимаемому месту. По этим показателям стек веток похож
+на разделяемые репозитории. Конечно стек веток имеет дополнительные
+преимущества:
+
+* Новая ветка может быть в абсолютно другом месте по сравнению с веткой на
+ которой она основана как стек.
+
+* Удаление ветки в стеке на самом деле удаляет ревизии (а не оставляет их в
+ разделяемом репозитории).
+
+* Стек веток более безопасен чем разделяемые репозитории, т.к. репозиторий на
+ котором основан стек может иметь доступ только для чтения для разработчиков
+ которые фиксируют изменения на ветке в стеке.
+
+Эти преимущества делают стек веток идеальным выбором для различных сценариев,
+включая экспериментальные ветки и сайты с хостингом кода.
+
+
+Создание ветки в стеке
+----------------------
+
+Что бы создать ветку в стеке нужно использовать опцию ``stacked`` для команды
+``branch``. Например::
+
+ bzr branch --stacked source-url my-dir
+
+Здесь мы создадим ``my-dir`` как ветку в стеке без локальных ревизий. Если
+определено открытая ветка связанная с ``source-url`` будет использована как
+*основа стека*. Иначе ``source-url`` будет *основой стека*.
+
+
+Создание рабочего каталога в стеке
+-----------------------------------
+
+Поддержка прямого создания рабочего каталога в стеке скоро ожидается. Пока
+для этого требуется два шага:
+
+1. Создать ветку в стеке, как описано выше.
+
+2. Конвертировать ветку в рабочий каталог используя либо команду
+ ``reconfigure``, либо команду ``bind``.
+
+
+Публикация ветки в стеке
+------------------------
+
+Многие изменения в большинстве проектов создаются на основе готовых веток,
+таких как *основная линия разработки*, или *текущая стабильная*. Создание новой
+ветки в стеке основанной на таких ветках легко сделать с использованием команды
+``push``::
+
+ bzr push --stacked-on reference-url my-url
+
+Эта команда создаст новую ветку ``my-url``, которая будет основана на
+``reference-url`` и содержать только ревизии из текущей ветки, которых еще нет
+на ветке ``reference-url``.
+
+Если локальная ветка была создана как ветка в стеке то мы можем использовать
+опцию ``--stacked`` для команды ``push`` и тогда ветка на которой будет основан
+стек будет задана неявно. Например::
+
+ bzr branch --stacked source-url my-dir
+ cd my-dir
+ (меняем, меняем, меняем)
+ bzr commit -m "исправление ошибки"
+ bzr push --stacked
+
+
+Ограничения веток в стеке
+-------------------------
+
+Важная вещь которую надо запомнить в отношении веток в стеке - ветка на которой
+основан стек должна быть доступна практически для всех операций. Конечно это не
+проблема если обе ветки локальные, или находятся на одном сервере.
diff --git a/doc/ru/user-guide/using_checkouts.txt b/doc/ru/user-guide/using_checkouts.txt
new file mode 100644
index 0000000..6979fe9
--- /dev/null
+++ b/doc/ru/user-guide/using_checkouts.txt
@@ -0,0 +1,98 @@
+Using checkouts
+===============
+
+Turning a branch into a checkout
+--------------------------------
+
+If you have a local branch and wish to make it a checkout, use the
+``bind`` command like this::
+
+ bzr bind sftp://centralhost/srv/bzr/PROJECT/trunk
+
+This is necessary, for example, after creating a central branch using
+``push`` as illustrated in the previous section.
+
+After this, commits will be applied to the bound branch before
+being applied locally.
+
+Turning a checkout into a branch
+--------------------------------
+
+If you have a checkout and wish to make it a normal branch, use the
+``unbind`` command like this::
+
+ bzr unbind
+
+After this, commits will only be applied locally.
+
+Getting a checkout
+------------------
+
+When working in a team using a central branch, one person needs
+to provide some initial content as shown in the previous section.
+After that, each person should use the ``checkout`` command to
+create their local checkout, i.e. the sandbox in which they
+will make their changes.
+
+Unlike Subversion and CVS, in Bazaar the ``checkout`` command creates a
+local full copy of history in addition to creating a working tree holding
+the latest content. This means that operations such as ``diff`` and ``log``
+are fast and can still be used when disconnected from the central location.
+
+.. _getting-a-lightweight-checkout:
+
+Создание легковесной рабочей копии
+----------------------------------
+
+While Bazaar does its best to efficiently store version history, there
+are occasions when the history is simply not wanted. For example, if your
+team is managing the content of a web site using Bazaar with a
+central repository, then your release process might be as simple as
+updating a checkout of the content on the public web server. In this
+case, you probably don't want the history downloaded to that location
+as doing so:
+
+ * wastes disk space holding history that isn't needed there
+ * exposes a Bazaar branch that you may want kept private.
+
+To get a history-less checkout in Bazaar, use the ``--lightweight``
+option like this::
+
+ bzr checkout --lightweight sftp://centralhost/srv/bzr/PROJECT/trunk
+
+Of course, many of the benefits of a normal checkout are lost by doing
+this but that's a tradeoff you can make if and when it makes sense.
+
+The ``--lightweight`` option only applies to checkouts, not to all branches.
+
+Note: If your code base is really large and disk space on your computer
+is limited, lightweight checkouts may be the right choice for you.
+Be sure to consider all your options though including
+`shared repositories <#a-reminder-about-shared-repositories>`_,
+`stacked branches <#using-stacked-branches>`_, and `reusing a checkout`_.
+
+Updating to the latest content
+------------------------------
+
+One of the important aspects of working in lockstep with others is
+keeping your checkout up to date with the latest changes made to
+the central branch. Just as you would in Subversion or CVS, you do
+this in Bazaar by using the ``update`` command like this::
+
+ bzr update
+
+This gets any new revisions available in the bound branch and
+merges your local changes, if any.
+
+Handling commit failures
+------------------------
+
+Note that your checkout *must* be up to date with the bound branch
+before running ``commit``. Bazaar is actually stricter about this
+than Subversion or CVS - you need to be up to date with the full
+tree, not just for the files you've changed. Bazaar will ask you
+to run ``update`` if it detects that a revision has been added to
+the central location since you last updated.
+
+If the network connection to the bound branch is lost, the commit will
+fail. Some alternative ways of working around that are outlined next.
diff --git a/doc/ru/user-guide/zen.txt b/doc/ru/user-guide/zen.txt
new file mode 100644
index 0000000..bcf3f0c
--- /dev/null
+++ b/doc/ru/user-guide/zen.txt
@@ -0,0 +1,215 @@
+Путь Bazaar
+===========
+
+Глубокое понимание Bazaar
+-------------------------
+
+Хотя Bazaar во многом похож на другие инструменты контроля версий, есть
+некоторые важные различия, которые не всегда очевидны на первый взгляд. Этот
+раздел пытается объяснить некоторые вещи, который пользователь должен знать
+чтобы разбираться в Bazaar, т.е. глубоко его понимать.
+
+Заметьте: чтобы использовать Bazaar совсем необязательно полностью понимать
+этот раздел. Вы можете просмотреть этот раздел сейчас и вернуться к нему позже.
+
+Понимание номеров ревизий
+-------------------------
+
+All revisions in the mainline of a branch have a simple increasing
+integer. (First commit gets 1, 10th commit gets 10, etc.) This makes them
+fairly natural to use when you want to say "grab the 10th revision from my
+branch", or "fixed in revision 3050".
+
+For revisions which have been merged into a branch, a dotted notation is used
+(e.g., 3112.1.5). Dotted revision numbers have three numbers [#]_. The first
+number indicates what mainline revision change is derived from. The second
+number is the branch counter. There can be many branches derived from the
+same revision, so they all get a unique number. The third number is the
+number of revisions since the branch started. For example, 3112.1.5 is the
+first branch from revision 3112, the fifth revision on that branch.
+
+.. [#] Versions prior to bzr 1.2 used a slightly different algorithm.
+ Some nested branches would get extra numbers (such as 1.1.1.1.1)
+ rather than the simpler 3-number system.
+
+Hierarchical history is good
+----------------------------
+
+Imagine a project with multiple developers contributing changes where
+many changes consist of a series of commits. To give a concrete example,
+consider the case where:
+
+ * The tip of the project's trunk is revision 100.
+ * Mary makes 3 changes to deliver feature X.
+ * Bill makes 4 changes to deliver feature Y.
+
+If the developers are working in parallel and using a traditional
+centralized VCS approach, the project history will most likely be linear
+with Mary's changes and Bill's changes interleaved. It might look like this::
+
+ 107: Add documentation for Y
+ 106: Fix bug found in testing Y
+ 105: Fix bug found in testing X
+ 104: Add code for Y
+ 103: Add documentation for X
+ 102: Add code and tests for X
+ 101: Add tests for Y
+ 100: ...
+
+Many teams use this approach because their tools make branching and merging
+difficult. As a consequence, developers update from and commit to the trunk
+frequently, minimizing integration pain by spreading it over every commit.
+If you wish, you can use Bazaar exactly like this. Bazaar does offer other
+ways though that you ought to consider.
+
+An alternative approach encouraged by distributed VCS tools is to create
+feature branches and to integrate those when they are ready. In this case,
+Mary's feature branch would look like this::
+
+ 103: Fix bug found in testing X
+ 102: Add documentation for X
+ 101: Add code and tests for X
+ 100: ...
+
+And Bill's would look like this::
+
+ 104: Add documentation for Y
+ 103: Fix bug found in testing Y
+ 102: Add code for Y
+ 101: Add tests for Y
+ 100: ...
+
+If the features were independent and you wanted to keep linear history,
+the changes could be pushed back into the trunk in batches. (Technically,
+there are several ways of doing that but that's beyond the scope of
+this discussion.) The resulting history might look like this::
+
+ 107: Fix bug found in testing X
+ 106: Add documentation for X
+ 105: Add code and tests for X
+ 104: Add documentation for Y
+ 103: Fix bug found in testing Y
+ 102: Add code for Y
+ 101: Add tests for Y
+ 100: ...
+
+While this takes a bit more effort to achieve, it has some advantages over
+having revisions randomly intermixed. Better still though, branches can
+be merged together forming a non-linear history. The result might look
+like this::
+
+ 102: Merge feature X
+ 100.2.3: Fix bug found in testing X
+ 100.2.2: Add documentation for X
+ 100.2.1: Add code and tests for X
+ 101: Merge feature Y
+ 100.1.4: Add documentation for Y
+ 100.1.3: Fix bug found in testing Y
+ 100.1.2: Add code for Y
+ 100.1.1: Add tests for Y
+ 100: ...
+
+Or more likely this::
+
+ 102: Merge feature X
+ 100.2.3: Fix bug
+ 100.2.2: Add documentation
+ 100.2.1: Add code and tests
+ 101: Merge feature Y
+ 100.1.4: Add documentation
+ 100.1.3: Fix bug found in testing
+ 100.1.2: Add code
+ 100.1.1: Add tests
+ 100: ...
+
+This is considered good for many reasons:
+
+ * It makes it easier to understand the history of a project.
+ Related changes are clustered together and clearly partitioned.
+
+ * You can easily collapse history to see just the commits on the mainline
+ of a branch. When viewing the trunk history like this, you only see
+ high level commits (instead of a large number of commits uninteresting
+ at this level).
+
+ * If required, it makes backing out a feature much easier.
+
+ * Continuous integration tools can be used to ensure that
+ all tests still pass before committing a merge to the mainline.
+ (In many cases, it isn't appropriate to trigger CI tools after
+ every single commit as some tests will fail during development.
+ In fact, adding the tests first - TDD style - will guarantee it!)
+
+In summary, the important points are:
+
+ *Organize your work using branches.*
+
+ *Integrate changes using merge.*
+
+ *Ordered revision numbers and hierarchy make history easier to follow.*
+
+
+Each branch has its own view of history
+---------------------------------------
+
+As explained above, Bazaar makes the distinction between:
+
+ * mainline revisions, i.e. ones you committed in your branch, and
+
+ * merged revisions, i.e. ones added as ancestors by committing a merge.
+
+Each branch effectively has its own view of history, i.e. different
+branches can give the same revision a different "local" revision number.
+Mainline revisions always get allocated single number revision numbers
+while merged revisions always get allocated dotted revision numbers.
+
+To extend the example above, here's what the revision history of
+Mary's branch would look like had she decided to merge the project
+trunk into her branch after completing her changes::
+
+ 104: Merge mainline
+ 100.2.1: Merge feature Y
+ 100.1.4: Add documentation
+ 100.1.3: Fix bug found in testing
+ 100.1.2: Add code
+ 100.1.1: Add tests
+ 103: Fix bug found in testing X
+ 102: Add documentation for X
+ 101: Add code and tests for X
+ 100: ...
+
+Once again, it's easy for Mary to look at just *her* top level of history
+to see the steps she has taken to develop this change. In this context,
+merging the trunk (and resolving any conflicts caused by doing that) is
+just one step as far as the history of this branch is concerned.
+
+It's important to remember that Bazaar is not changing history here, nor
+is it changing the global revision identifiers. You can always use the
+latter if you really want to. In fact, you can use the branch specific
+revision numbers when communicating *as long as* you provide the branch
+URL as context. (In many Bazaar projects, developers imply the central
+trunk branch if they exchange a revision number without a branch URL.)
+
+Merges do not change revision numbers in a branch, though they do
+allocate local revision numbers to newly merged revisions. The only time
+Bazaar will change revision numbers in a branch is when you explicitly
+ask it to mirror another branch.
+
+Note: Revisions are numbered in a stable way: if two branches have
+the same revision in their mainline, all revisions in the ancestry of that
+revision will have the same revision numbers. For example, if Alice and Bob's
+branches agree on revision 10, they will agree on all revisions before
+that.
+
+Резюме
+------
+
+Обычно, если вы следовали ранее полученным советам - организовать вашу работу
+в ветках и использовать объединение для сотрудничества - вы обнаружите что
+чаще всего Bazaar делает то что вы ожидаете.
+
+В следующих главах, мы проверим различный способы использования Bazaar, начиная
+с самого простого: использование Bazaar для личных проектов.
+
+..
+ vim: ft=rst tw=74 ai