<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Advanced Topics — Bazaar 2.7.0 documentation</title>
<link rel="stylesheet" href="../_static/classic.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<script type="text/javascript" src="../_static/language_data.js"></script>
<link rel="shortcut icon" href="../_static/bzr.ico"/>
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="Licence" href="licence.html" />
<link rel="prev" title="Upgrades" href="upgrade.html" />
</head><body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="licence.html" title="Licence"
accesskey="N">next</a></li>
<li class="right" >
<a href="upgrade.html" title="Upgrades"
accesskey="P">previous</a> |</li>
<li><a href="http://bazaar.canonical.com/">
<img src="../_static/bzr icon 16.png" /> Home</a> | </li>
<a href="http://doc.bazaar.canonical.com/en/">Documentation</a> | </li>
<li class="nav-item nav-item-0"><a href="../index.html">Table of Contents (2.7.0)</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">Bazaar System Administrator’s Guide</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="advanced-topics">
<h1>Advanced Topics<a class="headerlink" href="#advanced-topics" title="Permalink to this headline">¶</a></h1>
<div class="section" id="system-monitoring">
<h2>System Monitoring<a class="headerlink" href="#system-monitoring" title="Permalink to this headline">¶</a></h2>
</div>
<div class="section" id="capacity-planning-tips">
<h2>Capacity Planning Tips<a class="headerlink" href="#capacity-planning-tips" title="Permalink to this headline">¶</a></h2>
</div>
<div class="section" id="clustering">
<h2>Clustering<a class="headerlink" href="#clustering" title="Permalink to this headline">¶</a></h2>
</div>
<div class="section" id="multi-site-setups">
<h2>Multi-site Setups<a class="headerlink" href="#multi-site-setups" title="Permalink to this headline">¶</a></h2>
<p>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.</p>
<p>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.)</p>
<p>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-<em>site</em> development, we
will persist in this naming scheme.</p>
<div class="section" id="setup">
<h3>Setup<a class="headerlink" href="#setup" title="Permalink to this headline">¶</a></h3>
<p>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.</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ cd /srv/bzr/projectx
$ mv trunk trunk # can simply rename on the filesystem
$ bzr branch trunk texas-integration # very fast in a shared repository
</pre></div>
</div>
<p>In Australia, we need to set up the <code class="docutils literal notranslate"><span class="pre">/srv/bzr/projectx</span></code> directory and get a
copy of the current trunk as australia-integration:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ 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
</pre></div>
</div>
</div>
<div class="section" id="merging-to-master">
<h3>Merging to master<a class="headerlink" href="#merging-to-master" title="Permalink to this headline">¶</a></h3>
<p>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:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span># 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"
</pre></div>
</div>
<p>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
<code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">merge</span> <span class="pre">--pull</span></code>.</p>
</div>
<div class="section" id="merging-back-to-local-trunks">
<h3>Merging back to local trunks<a class="headerlink" href="#merging-back-to-local-trunks" title="Permalink to this headline">¶</a></h3>
<p>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
<code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">pull</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ 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
</pre></div>
</div>
<p>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:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr merge ../trunk
# Run test suite, resolve conflicts
$ bzr commit -m "Merging Australian changes"
</pre></div>
</div>
<p>In Australia, they will need to update their local copy of trunk:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ cd /srv/bzr/projectx/trunk
$ bzr pull # parent location is used by default
</pre></div>
</div>
<p>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:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ 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"
</pre></div>
</div>
</div>
<div class="section" id="other-considerations">
<h3>Other Considerations<a class="headerlink" href="#other-considerations" title="Permalink to this headline">¶</a></h3>
<p>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.</p>
<p>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.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="../index.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Advanced Topics</a><ul>
<li><a class="reference internal" href="#system-monitoring">System Monitoring</a></li>
<li><a class="reference internal" href="#capacity-planning-tips">Capacity Planning Tips</a></li>
<li><a class="reference internal" href="#clustering">Clustering</a></li>
<li><a class="reference internal" href="#multi-site-setups">Multi-site Setups</a><ul>
<li><a class="reference internal" href="#setup">Setup</a></li>
<li><a class="reference internal" href="#merging-to-master">Merging to master</a></li>
<li><a class="reference internal" href="#merging-back-to-local-trunks">Merging back to local trunks</a></li>
<li><a class="reference internal" href="#other-considerations">Other Considerations</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="upgrade.html"
title="previous chapter">Upgrades</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="licence.html"
title="next chapter">Licence</a></p>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/admin-guide/advanced.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="licence.html" title="Licence"
>next</a></li>
<li class="right" >
<a href="upgrade.html" title="Upgrades"
>previous</a> |</li>
<li><a href="http://bazaar.canonical.com/">
<img src="../_static/bzr icon 16.png" /> Home</a> | </li>
<a href="http://doc.bazaar.canonical.com/en/">Documentation</a> | </li>
<li class="nav-item nav-item-0"><a href="../index.html">Table of Contents (2.7.0)</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" >Bazaar System Administrator’s Guide</a> »</li>
</ul>
</div>
<div class="footer" role="contentinfo">
© Copyright 2009-2011 Canonical Ltd.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
</div>
</body>
</html>
