Merge lp:~jelmer/brz/auto-rename-fix into lp:brz

[Jelmer Vernooij]

Fixed bug with RenameMap (bzr move --auto), also RenameMap has ability to detect files moved into new unversioned directories.

(Original MP at https://code.launchpad.net/~mnn282/bzr/auto-rename-fix/+merge/117203)

[Martin Packman (gz)]

Looks good with change to test mentioned.

review: Approve

=== modified file 'breezy/rename_map.py'
--- breezy/rename_map.py	2017-06-05 20:48:31 +0000
+++ breezy/rename_map.py	2017-11-11 18:32:23 +0000
@@ -186,7 +186,8 @@
             for (file_id, paths, changed_content, versioned, parent, name,
                  kind, executable) in iterator:
                 if kind[1] is None and versioned[1]:
-                    missing_parents.setdefault(parent[0], set()).add(file_id)
+                    if not self.tree.has_filename(self.tree.id2path(parent[0])):
+                        missing_parents.setdefault(parent[0], set()).add(file_id)
                     if kind[0] == 'file':
                         missing_files.add(file_id)
                     else:
@@ -258,6 +259,12 @@
             parent_id = matches.get(parent_path)
             if parent_id is None:
                 parent_id = self.tree.path2id(parent_path)
+                if parent_id is None:
+                    added, ignored = self.tree.smart_add([parent_path], recurse=False)
+                    if len(ignored) > 0 and ignored[0] == parent_path:
+                        continue
+                    else:
+                        parent_id = self.tree.path2id(parent_path)
             if entry.name == new_name and entry.parent_id == parent_id:
                 continue
             new_entry = entry.copy()

=== modified file 'breezy/tests/test_groupcompress.py'
--- breezy/tests/test_groupcompress.py	2017-10-27 00:18:42 +0000
+++ breezy/tests/test_groupcompress.py	2017-11-11 18:32:23 +0000
@@ -53,7 +53,7 @@
 class TestGroupCompressor(tests.TestCase):
 
     def _chunks_to_repr_lines(self, chunks):
-        return '\n'.join(map(repr, ''.join(chunks).split('\n')))
+        return '\n'.join(map(repr, b''.join(chunks).split(b'\n')))
 
     def assertEqualDiffEncoded(self, expected, actual):
         """Compare the actual content to the expected content.
@@ -82,18 +82,18 @@
         # diff against NUKK
         compressor = self.compressor()
         sha1, start_point, end_point, _ = compressor.compress(('label',),
-            'strange\ncommon\n', None)
-        self.assertEqual(sha_string('strange\ncommon\n'), sha1)
-        expected_lines = 'f' '\x0f' 'strange\ncommon\n'
-        self.assertEqual(expected_lines, ''.join(compressor.chunks))
+            b'strange\ncommon\n', None)
+        self.assertEqual(sha_string(b'strange\ncommon\n'), sha1)
+        expected_lines = b'f\x0fstrange\ncommon\n'
+        self.assertEqual(expected_lines, b''.join(compressor.chunks))
         self.assertEqual(0, start_point)
-        self.assertEqual(sum(map(len, expected_lines)), end_point)
+        self.assertEqual(len(expected_lines), end_point)
 
     def test_empty_content(self):
         compressor = self.compressor()
         # Adding empty bytes should return the 'null' record
         sha1, start_point, end_point, kind = compressor.compress(('empty',),
-                                                                 '', None)
+                                                                 b'', None)
         self.assertEqual(0, start_point)
         self.assertEqual(0, end_point)
         self.assertEqual('fulltext', kind)
@@ -101,10 +101,10 @@
         self.assertEqual(0, compressor.endpoint)
         self.assertEqual([], compressor.chunks)
         # Even after adding some content
-        compressor.compress(('content',), 'some\nbytes\n', None)
+        compressor.compress(('content',), b'some\nbytes\n', None)
         self.assertTrue(compressor.endpoint > 0)
         sha1, start_point, end_point, kind = compressor.compress(('empty2',),
-                                                                 '', None)
+                                                                 b'', None)
         self.assertEqual(0, start_point)
         self.assertEqual(0, end_point)
         self.assertEqual('fulltext', kind)
@@ -115,26 +115,26 @@
         # reading something that is in the compressor stream already.
         compressor = self.compressor()
         sha1_1, _, _, _ = compressor.compress(('label',),
-            'strange\ncommon long line\nthat needs a 16 byte match\n', None)
+            b'strange\ncommon long line\nthat needs a 16 byte match\n', None)
         expected_lines = list(compressor.chunks)
         sha1_2, _, end_point, _ = compressor.compress(('newlabel',),
-            'common long line\nthat needs a 16 byte match\ndifferent\n', None)
+            b'common long line\nthat needs a 16 byte match\ndifferent\n', None)
         # get the first out
-        self.assertEqual(('strange\ncommon long line\n'
-                          'that needs a 16 byte match\n', sha1_1),
+        self.assertEqual((b'strange\ncommon long line\n'
+                          b'that needs a 16 byte match\n', sha1_1),
                          compressor.extract(('label',)))
         # and the second
-        self.assertEqual(('common long line\nthat needs a 16 byte match\n'
-                          'different\n', sha1_2),
+        self.assertEqual((b'common long line\nthat needs a 16 byte match\n'
+                          b'different\n', sha1_2),
                          compressor.extract(('newlabel',)))
 
     def test_pop_last(self):
         compressor = self.compressor()
         _, _, _, _ = compressor.compress(('key1',),
-            'some text\nfor the first entry\n', None)
+            b'some text\nfor the first entry\n', None)
         expected_lines = list(compressor.chunks)
         _, _, _, _ = compressor.compress(('key2',),
-            'some text\nfor the second entry\n', None)
+            b'some text\nfor the second entry\n', None)
         compressor.pop_last()
         self.assertEqual(expected_lines, compressor.chunks)
 
@@ -147,41 +147,41 @@
     def test_stats(self):
         compressor = self.compressor()
         compressor.compress(('label',),
-                            'strange\n'
-                            'common very very long line\n'
-                            'plus more text\n', None)
+                            b'strange\n'
+                            b'common very very long line\n'
+                            b'plus more text\n', None)
         compressor.compress(('newlabel',),
-                            'common very very long line\n'
-                            'plus more text\n'
-                            'different\n'
-                            'moredifferent\n', None)
+                            b'common very very long line\n'
+                            b'plus more text\n'
+                            b'different\n'
+                            b'moredifferent\n', None)
         compressor.compress(('label3',),
-                            'new\n'
-                            'common very very long line\n'
-                            'plus more text\n'
-                            'different\n'
-                            'moredifferent\n', None)
+                            b'new\n'
+                            b'common very very long line\n'
+                            b'plus more text\n'
+                            b'different\n'
+                            b'moredifferent\n', None)
         self.assertAlmostEqual(1.9, compressor.ratio(), 1)
 
     def test_two_nosha_delta(self):
         compressor = self.compressor()
         sha1_1, _, _, _ = compressor.compress(('label',),
-            'strange\ncommon long line\nthat needs a 16 byte match\n', None)
+            b'strange\ncommon long line\nthat needs a 16 byte match\n', None)
         expected_lines = list(compressor.chunks)
         sha1_2, start_point, end_point, _ = compressor.compress(('newlabel',),
-            'common long line\nthat needs a 16 byte match\ndifferent\n', None)
-        self.assertEqual(sha_string('common long line\n'
-                                    'that needs a 16 byte match\n'
-                                    'different\n'), sha1_2)
+            b'common long line\nthat needs a 16 byte match\ndifferent\n', None)
+        self.assertEqual(sha_string(b'common long line\n'
+                                    b'that needs a 16 byte match\n'
+                                    b'different\n'), sha1_2)
         expected_lines.extend([
             # 'delta', delta length
-            'd\x0f',
+            b'd\x0f',
             # source and target length
-            '\x36',
+            b'\x36',
             # copy the line common
-            '\x91\x0a\x2c', #copy, offset 0x0a, len 0x2c
+            b'\x91\x0a\x2c', #copy, offset 0x0a, len 0x2c
             # add the line different, and the trailing newline
-            '\x0adifferent\n', # insert 10 bytes
+            b'\x0adifferent\n', # insert 10 bytes
             ])
         self.assertEqualDiffEncoded(expected_lines, compressor.chunks)
         self.assertEqual(sum(map(len, expected_lines)), end_point)
@@ -191,29 +191,29 @@
         # both parents.
         compressor = self.compressor()
         sha1_1, _, _, _ = compressor.compress(('label',),
-            'strange\ncommon very very long line\nwith some extra text\n', None)
+            b'strange\ncommon very very long line\nwith some extra text\n', None)
         sha1_2, _, _, _ = compressor.compress(('newlabel',),
-            'different\nmoredifferent\nand then some more\n', None)
+            b'different\nmoredifferent\nand then some more\n', None)
         expected_lines = list(compressor.chunks)
         sha1_3, start_point, end_point, _ = compressor.compress(('label3',),
-            'new\ncommon very very long line\nwith some extra text\n'
-            'different\nmoredifferent\nand then some more\n',
+            b'new\ncommon very very long line\nwith some extra text\n'
+            b'different\nmoredifferent\nand then some more\n',
             None)
         self.assertEqual(
-            sha_string('new\ncommon very very long line\nwith some extra text\n'
-                       'different\nmoredifferent\nand then some more\n'),
+            sha_string(b'new\ncommon very very long line\nwith some extra text\n'
+                       b'different\nmoredifferent\nand then some more\n'),
             sha1_3)
         expected_lines.extend([
             # 'delta', delta length
-            'd\x0b',
+            b'd\x0b',
             # source and target length
-            '\x5f'
+            b'\x5f'
             # insert new
-            '\x03new',
+            b'\x03new',
             # Copy of first parent 'common' range
-            '\x91\x09\x31' # copy, offset 0x09, 0x31 bytes
+            b'\x91\x09\x31' # copy, offset 0x09, 0x31 bytes
             # Copy of second parent 'different' range
-            '\x91\x3c\x2b' # copy, offset 0x3c, 0x2b bytes
+            b'\x91\x3c\x2b' # copy, offset 0x3c, 0x2b bytes
             ])
         self.assertEqualDiffEncoded(expected_lines, compressor.chunks)
         self.assertEqual(sum(map(len, expected_lines)), end_point)
@@ -226,41 +226,41 @@
     def test_stats(self):
         compressor = self.compressor()
         compressor.compress(('label',),
-                            'strange\n'
-                            'common very very long line\n'
-                            'plus more text\n', None)
+                            b'strange\n'
+                            b'common very very long line\n'
+                            b'plus more text\n', None)
         compressor.compress(('newlabel',),
-                            'common very very long line\n'
-                            'plus more text\n'
-                            'different\n'
-                            'moredifferent\n', None)
+                            b'common very very long line\n'
+                            b'plus more text\n'
+                            b'different\n'
+                            b'moredifferent\n', None)
         compressor.compress(('label3',),
-                            'new\n'
-                            'common very very long line\n'
-                            'plus more text\n'
-                            'different\n'
-                            'moredifferent\n', None)
+                            b'new\n'
+                            b'common very very long line\n'
+                            b'plus more text\n'
+                            b'different\n'
+                            b'moredifferent\n', None)
         self.assertAlmostEqual(1.9, compressor.ratio(), 1)
 
     def test_two_nosha_delta(self):
         compressor = self.compressor()
         sha1_1, _, _, _ = compressor.compress(('label',),
-            'strange\ncommon long line\nthat needs a 16 byte match\n', None)
+            b'strange\ncommon long line\nthat needs a 16 byte match\n', None)
         expected_lines = list(compressor.chunks)
         sha1_2, start_point, end_point, _ = compressor.compress(('newlabel',),
-            'common long line\nthat needs a 16 byte match\ndifferent\n', None)
-        self.assertEqual(sha_string('common long line\n'
-                                    'that needs a 16 byte match\n'
-                                    'different\n'), sha1_2)
+            b'common long line\nthat needs a 16 byte match\ndifferent\n', None)
+        self.assertEqual(sha_string(b'common long line\n'
+                                    b'that needs a 16 byte match\n'
+                                    b'different\n'), sha1_2)
         expected_lines.extend([
             # 'delta', delta length
-            'd\x0f',
+            b'd\x0f',
             # target length
-            '\x36',
+            b'\x36',
             # copy the line common
-            '\x91\x0a\x2c', #copy, offset 0x0a, len 0x2c
+            b'\x91\x0a\x2c', #copy, offset 0x0a, len 0x2c
             # add the line different, and the trailing newline
-            '\x0adifferent\n', # insert 10 bytes
+            b'\x0adifferent\n', # insert 10 bytes
             ])
         self.assertEqualDiffEncoded(expected_lines, compressor.chunks)
         self.assertEqual(sum(map(len, expected_lines)), end_point)
@@ -270,29 +270,29 @@
         # both parents.
         compressor = self.compressor()
         sha1_1, _, _, _ = compressor.compress(('label',),
-            'strange\ncommon very very long line\nwith some extra text\n', None)
+            b'strange\ncommon very very long line\nwith some extra text\n', None)
         sha1_2, _, _, _ = compressor.compress(('newlabel',),
-            'different\nmoredifferent\nand then some more\n', None)
+            b'different\nmoredifferent\nand then some more\n', None)
         expected_lines = list(compressor.chunks)
         sha1_3, start_point, end_point, _ = compressor.compress(('label3',),
-            'new\ncommon very very long line\nwith some extra text\n'
-            'different\nmoredifferent\nand then some more\n',
+            b'new\ncommon very very long line\nwith some extra text\n'
+            b'different\nmoredifferent\nand then some more\n',
             None)
         self.assertEqual(
-            sha_string('new\ncommon very very long line\nwith some extra text\n'
-                       'different\nmoredifferent\nand then some more\n'),
+            sha_string(b'new\ncommon very very long line\nwith some extra text\n'
+                       b'different\nmoredifferent\nand then some more\n'),
             sha1_3)
         expected_lines.extend([
             # 'delta', delta length
-            'd\x0c',
+            b'd\x0c',
             # target length
-            '\x5f'
+            b'\x5f'
             # insert new
-            '\x04new\n',
+            b'\x04new\n',
             # Copy of first parent 'common' range
-            '\x91\x0a\x30' # copy, offset 0x0a, 0x30 bytes
+            b'\x91\x0a\x30' # copy, offset 0x0a, 0x30 bytes
             # Copy of second parent 'different' range
-            '\x91\x3c\x2b' # copy, offset 0x3c, 0x2b bytes
+            b'\x91\x3c\x2b' # copy, offset 0x3c, 0x2b bytes
             ])
         self.assertEqualDiffEncoded(expected_lines, compressor.chunks)
         self.assertEqual(sum(map(len, expected_lines)), end_point)
@@ -316,32 +316,32 @@
 
     def test_from_empty_bytes(self):
         self.assertRaises(ValueError,
-                          groupcompress.GroupCompressBlock.from_bytes, '')
+                          groupcompress.GroupCompressBlock.from_bytes, b'')
 
     def test_from_minimal_bytes(self):
         block = groupcompress.GroupCompressBlock.from_bytes(
-            'gcb1z\n0\n0\n')
+            b'gcb1z\n0\n0\n')
         self.assertIsInstance(block, groupcompress.GroupCompressBlock)
         self.assertIs(None, block._content)
-        self.assertEqual('', block._z_content)
+        self.assertEqual(b'', block._z_content)
         block._ensure_content()
-        self.assertEqual('', block._content)
-        self.assertEqual('', block._z_content)
+        self.assertEqual(b'', block._content)
+        self.assertEqual(b'', block._z_content)
         block._ensure_content() # Ensure content is safe to call 2x
 
     def test_from_invalid(self):
         self.assertRaises(ValueError,
                           groupcompress.GroupCompressBlock.from_bytes,
-                          'this is not a valid header')
+                          b'this is not a valid header')
 
     def test_from_bytes(self):
-        content = ('a tiny bit of content\n')
+        content = (b'a tiny bit of content\n')
         z_content = zlib.compress(content)
         z_bytes = (
-            'gcb1z\n' # group compress block v1 plain
-            '%d\n' # Length of compressed content
-            '%d\n' # Length of uncompressed content
-            '%s'   # Compressed content
+            b'gcb1z\n' # group compress block v1 plain
+            b'%d\n' # Length of compressed content
+            b'%d\n' # Length of uncompressed content
+            b'%s'   # Compressed content
             ) % (len(z_content), len(content), z_content)
         block = groupcompress.GroupCompressBlock.from_bytes(
             z_bytes)
@@ -354,20 +354,20 @@
         self.assertEqual(content, block._content)
 
     def test_to_chunks(self):
-        content_chunks = ['this is some content\n',
-                          'this content will be compressed\n']
+        content_chunks = [b'this is some content\n',
+                          b'this content will be compressed\n']
         content_len = sum(map(len, content_chunks))
-        content = ''.join(content_chunks)
+        content = b''.join(content_chunks)
         gcb = groupcompress.GroupCompressBlock()
         gcb.set_chunked_content(content_chunks, content_len)
         total_len, block_chunks = gcb.to_chunks()
-        block_bytes = ''.join(block_chunks)
+        block_bytes = b''.join(block_chunks)
         self.assertEqual(gcb._z_content_length, len(gcb._z_content))
         self.assertEqual(total_len, len(block_bytes))
         self.assertEqual(gcb._content_length, content_len)
-        expected_header =('gcb1z\n' # group compress block v1 zlib
-                          '%d\n' # Length of compressed content
-                          '%d\n' # Length of uncompressed content
+        expected_header =(b'gcb1z\n' # group compress block v1 zlib
+                          b'%d\n' # Length of compressed content
+                          b'%d\n' # Length of uncompressed content
                          ) % (gcb._z_content_length, gcb._content_length)
         # The first chunk should be the header chunk. It is small, fixed size,
         # and there is no compelling reason to split it up
@@ -378,30 +378,30 @@
         self.assertEqual(content, raw_bytes)
 
     def test_to_bytes(self):
-        content = ('this is some content\n'
-                   'this content will be compressed\n')
+        content = (b'this is some content\n'
+                   b'this content will be compressed\n')
         gcb = groupcompress.GroupCompressBlock()
         gcb.set_content(content)
-        bytes = gcb.to_bytes()
+        data = gcb.to_bytes()
         self.assertEqual(gcb._z_content_length, len(gcb._z_content))
         self.assertEqual(gcb._content_length, len(content))
-        expected_header =('gcb1z\n' # group compress block v1 zlib
-                          '%d\n' # Length of compressed content
-                          '%d\n' # Length of uncompressed content
+        expected_header =(b'gcb1z\n' # group compress block v1 zlib
+                          b'%d\n' # Length of compressed content
+                          b'%d\n' # Length of uncompressed content
                          ) % (gcb._z_content_length, gcb._content_length)
-        self.assertStartsWith(bytes, expected_header)
-        remaining_bytes = bytes[len(expected_header):]
+        self.assertStartsWith(data, expected_header)
+        remaining_bytes = data[len(expected_header):]
         raw_bytes = zlib.decompress(remaining_bytes)
         self.assertEqual(content, raw_bytes)
 
         # we should get the same results if using the chunked version
         gcb = groupcompress.GroupCompressBlock()
-        gcb.set_chunked_content(['this is some content\n'
-                                 'this content will be compressed\n'],
+        gcb.set_chunked_content([b'this is some content\n'
+                                 b'this content will be compressed\n'],
                                  len(content))
-        old_bytes = bytes
-        bytes = gcb.to_bytes()
-        self.assertEqual(old_bytes, bytes)
+        old_data = data
+        data = gcb.to_bytes()
+        self.assertEqual(old_data, data)
 
     def test_partial_decomp(self):
         content_chunks = []
@@ -410,11 +410,11 @@
         # compresses a bit too well, we want a combination, so we combine a sha
         # hash with compressible data.
         for i in range(2048):
-            next_content = '%d\nThis is a bit of duplicate text\n' % (i,)
+            next_content = b'%d\nThis is a bit of duplicate text\n' % (i,)
             content_chunks.append(next_content)
             next_sha1 = osutils.sha_string(next_content)
-            content_chunks.append(next_sha1 + '\n')
-        content = ''.join(content_chunks)
+            content_chunks.append(next_sha1 + b'\n')
+        content = b''.join(content_chunks)
         self.assertEqual(158634, len(content))
         z_content = zlib.compress(content)
         self.assertEqual(57182, len(z_content))
@@ -455,11 +455,11 @@
         # compresses a bit too well, we want a combination, so we combine a sha
         # hash with compressible data.
         for i in range(2048):
-            next_content = '%d\nThis is a bit of duplicate text\n' % (i,)
+            next_content = b'%d\nThis is a bit of duplicate text\n' % (i,)
             content_chunks.append(next_content)
             next_sha1 = osutils.sha_string(next_content)
-            content_chunks.append(next_sha1 + '\n')
-        content = ''.join(content_chunks)
+            content_chunks.append(next_sha1 + b'\n')
+        content = b''.join(content_chunks)
         self.assertEqual(158634, len(content))
         z_content = zlib.compress(content)
         self.assertEqual(57182, len(z_content))
@@ -477,14 +477,14 @@
         self.assertIs(None, block._z_content_decompressor)
 
     def test__dump(self):
-        dup_content = 'some duplicate content\nwhich is sufficiently long\n'
-        key_to_text = {('1',): dup_content + '1 unique\n',
-                       ('2',): dup_content + '2 extra special\n'}
+        dup_content = b'some duplicate content\nwhich is sufficiently long\n'
+        key_to_text = {(b'1',): dup_content + b'1 unique\n',
+                       (b'2',): dup_content + b'2 extra special\n'}
         locs, block = self.make_block(key_to_text)
-        self.assertEqual([('f', len(key_to_text[('1',)])),
-                          ('d', 21, len(key_to_text[('2',)]),
-                           [('c', 2, len(dup_content)),
-                            ('i', len('2 extra special\n'), '')
+        self.assertEqual([(b'f', len(key_to_text[(b'1',)])),
+                          (b'd', 21, len(key_to_text[(b'2',)]),
+                           [(b'c', 2, len(dup_content)),
+                            (b'i', len(b'2 extra special\n'), b'')
                            ]),
                          ], block._dump())
 
@@ -516,10 +516,10 @@
         return btree_index.BTreeGraphIndex(trans, name, size)
 
     def make_g_index_missing_parent(self):
-        graph_index = self.make_g_index('missing_parent', 1,
-            [(('parent', ), '2 78 2 10', ([],)),
-             (('tip', ), '2 78 2 10',
-              ([('parent', ), ('missing-parent', )],)),
+        graph_index = self.make_g_index(b'missing_parent', 1,
+            [((b'parent', ), b'2 78 2 10', ([],)),
+             ((b'tip', ), b'2 78 2 10',
+              ([(b'parent', ), (b'missing-parent', )],)),
               ])
         return graph_index
 
@@ -527,76 +527,78 @@
         # Consider promoting 'as-requested' to general availability, and
         # make this a VF interface test
         vf = self.make_test_vf(False, dir='source')
-        vf.add_lines(('a',), (), ['lines\n'])
-        vf.add_lines(('b',), (), ['lines\n'])
-        vf.add_lines(('c',), (), ['lines\n'])
-        vf.add_lines(('d',), (), ['lines\n'])
+        vf.add_lines((b'a',), (), [b'lines\n'])
+        vf.add_lines((b'b',), (), [b'lines\n'])
+        vf.add_lines((b'c',), (), [b'lines\n'])
+        vf.add_lines((b'd',), (), [b'lines\n'])
         vf.writer.end()
         keys = [record.key for record in vf.get_record_stream(
-                    [('a',), ('b',), ('c',), ('d',)],
+                    [(b'a',), (b'b',), (b'c',), (b'd',)],
                     'as-requested', False)]
-        self.assertEqual([('a',), ('b',), ('c',), ('d',)], keys)
+        self.assertEqual([(b'a',), (b'b',), (b'c',), (b'd',)], keys)
         keys = [record.key for record in vf.get_record_stream(
-                    [('b',), ('a',), ('d',), ('c',)],
+                    [(b'b',), (b'a',), (b'd',), (b'c',)],
                     'as-requested', False)]
-        self.assertEqual([('b',), ('a',), ('d',), ('c',)], keys)
+        self.assertEqual([(b'b',), (b'a',), (b'd',), (b'c',)], keys)
 
         # It should work even after being repacked into another VF
         vf2 = self.make_test_vf(False, dir='target')
         vf2.insert_record_stream(vf.get_record_stream(
-                    [('b',), ('a',), ('d',), ('c',)], 'as-requested', False))
+                    [(b'b',), (b'a',), (b'd',), (b'c',)], 'as-requested', False))
         vf2.writer.end()
 
         keys = [record.key for record in vf2.get_record_stream(
-                    [('a',), ('b',), ('c',), ('d',)],
+                    [(b'a',), (b'b',), (b'c',), (b'd',)],
                     'as-requested', False)]
-        self.assertEqual([('a',), ('b',), ('c',), ('d',)], keys)
+        self.assertEqual([(b'a',), (b'b',), (b'c',), (b'd',)], keys)
         keys = [record.key for record in vf2.get_record_stream(
-                    [('b',), ('a',), ('d',), ('c',)],
+                    [(b'b',), (b'a',), (b'd',), (b'c',)],
                     'as-requested', False)]
-        self.assertEqual([('b',), ('a',), ('d',), ('c',)], keys)
+        self.assertEqual([(b'b',), (b'a',), (b'd',), (b'c',)], keys)
 
     def test_get_record_stream_max_bytes_to_index_default(self):
         vf = self.make_test_vf(True, dir='source')
-        vf.add_lines(('a',), (), ['lines\n'])
+        vf.add_lines((b'a',), (), [b'lines\n'])
         vf.writer.end()
-        record = next(vf.get_record_stream([('a',)], 'unordered', True))
+        record = next(vf.get_record_stream([(b'a',)], 'unordered', True))
         self.assertEqual(vf._DEFAULT_COMPRESSOR_SETTINGS,
                          record._manager._get_compressor_settings())
 
     def test_get_record_stream_accesses_compressor_settings(self):
         vf = self.make_test_vf(True, dir='source')
-        vf.add_lines(('a',), (), ['lines\n'])
+        vf.add_lines((b'a',), (), [b'lines\n'])
         vf.writer.end()
         vf._max_bytes_to_index = 1234
-        record = next(vf.get_record_stream([('a',)], 'unordered', True))
+        record = next(vf.get_record_stream([(b'a',)], 'unordered', True))
         self.assertEqual(dict(max_bytes_to_index=1234),
                          record._manager._get_compressor_settings())
 
+    @staticmethod
+    def grouped_stream(revision_ids, first_parents=()):
+        parents = first_parents
+        for revision_id in revision_ids:
+            key = (revision_id,)
+            record = versionedfile.FulltextContentFactory(
+                key, parents, None,
+                b'some content that is\n'
+                b'identical except for\n'
+                b'revision_id:%s\n' % (revision_id,))
+            yield record
+            parents = (key,)
+
     def test_insert_record_stream_reuses_blocks(self):
         vf = self.make_test_vf(True, dir='source')
-        def grouped_stream(revision_ids, first_parents=()):
-            parents = first_parents
-            for revision_id in revision_ids:
-                key = (revision_id,)
-                record = versionedfile.FulltextContentFactory(
-                    key, parents, None,
-                    'some content that is\n'
-                    'identical except for\n'
-                    'revision_id:%s\n' % (revision_id,))
-                yield record
-                parents = (key,)
         # One group, a-d
-        vf.insert_record_stream(grouped_stream(['a', 'b', 'c', 'd']))
+        vf.insert_record_stream(self.grouped_stream([b'a', b'b', b'c', b'd']))
         # Second group, e-h
-        vf.insert_record_stream(grouped_stream(['e', 'f', 'g', 'h'],
-                                               first_parents=(('d',),)))
+        vf.insert_record_stream(self.grouped_stream(
+            [b'e', b'f', b'g', b'h'], first_parents=((b'd',),)))
         block_bytes = {}
-        stream = vf.get_record_stream([(r,) for r in 'abcdefgh'],
-                                      'unordered', False)
+        stream = vf.get_record_stream(
+            [(r.encode(),) for r in 'abcdefgh'], 'unordered', False)
         num_records = 0
         for record in stream:
-            if record.key in [('a',), ('e',)]:
+            if record.key in [(b'a',), (b'e',)]:
                 self.assertEqual('groupcompress-block', record.storage_kind)
             else:
                 self.assertEqual('groupcompress-block-ref',
@@ -605,28 +607,27 @@
             num_records += 1
         self.assertEqual(8, num_records)
         for r in 'abcd':
-            key = (r,)
-            self.assertIs(block_bytes[key], block_bytes[('a',)])
-            self.assertNotEqual(block_bytes[key], block_bytes[('e',)])
+            key = (r.encode(),)
+            self.assertIs(block_bytes[key], block_bytes[(b'a',)])
+            self.assertNotEqual(block_bytes[key], block_bytes[(b'e',)])
         for r in 'efgh':
-            key = (r,)
-            self.assertIs(block_bytes[key], block_bytes[('e',)])
-            self.assertNotEqual(block_bytes[key], block_bytes[('a',)])
+            key = (r.encode(),)
+            self.assertIs(block_bytes[key], block_bytes[(b'e',)])
+            self.assertNotEqual(block_bytes[key], block_bytes[(b'a',)])
         # Now copy the blocks into another vf, and ensure that the blocks are
         # preserved without creating new entries
         vf2 = self.make_test_vf(True, dir='target')
+        keys = [(r.encode(),) for r in 'abcdefgh']
         # ordering in 'groupcompress' order, should actually swap the groups in
         # the target vf, but the groups themselves should not be disturbed.
         def small_size_stream():
-            for record in vf.get_record_stream([(r,) for r in 'abcdefgh'],
-                                               'groupcompress', False):
+            for record in vf.get_record_stream(keys, 'groupcompress', False):
                 record._manager._full_enough_block_size = \
                     record._manager._block._content_length
                 yield record
-                        
+
         vf2.insert_record_stream(small_size_stream())
-        stream = vf2.get_record_stream([(r,) for r in 'abcdefgh'],
-                                       'groupcompress', False)
+        stream = vf2.get_record_stream(keys, 'groupcompress', False)
         vf2.writer.end()
         num_records = 0
         for record in stream:
@@ -637,30 +638,19 @@
 
     def test_insert_record_stream_packs_on_the_fly(self):
         vf = self.make_test_vf(True, dir='source')
-        def grouped_stream(revision_ids, first_parents=()):
-            parents = first_parents
-            for revision_id in revision_ids:
-                key = (revision_id,)
-                record = versionedfile.FulltextContentFactory(
-                    key, parents, None,
-                    'some content that is\n'
-                    'identical except for\n'
-                    'revision_id:%s\n' % (revision_id,))
-                yield record
-                parents = (key,)
         # One group, a-d
-        vf.insert_record_stream(grouped_stream(['a', 'b', 'c', 'd']))
+        vf.insert_record_stream(self.grouped_stream([b'a', b'b', b'c', b'd']))
         # Second group, e-h
-        vf.insert_record_stream(grouped_stream(['e', 'f', 'g', 'h'],
-                                               first_parents=(('d',),)))
+        vf.insert_record_stream(self.grouped_stream(
+            [b'e', b'f', b'g', b'h'], first_parents=((b'd',),)))
         # Now copy the blocks into another vf, and see that the
         # insert_record_stream rebuilt a new block on-the-fly because of
         # under-utilization
         vf2 = self.make_test_vf(True, dir='target')
+        keys = [(r.encode(),) for r in 'abcdefgh']
         vf2.insert_record_stream(vf.get_record_stream(
-            [(r,) for r in 'abcdefgh'], 'groupcompress', False))
-        stream = vf2.get_record_stream([(r,) for r in 'abcdefgh'],
-                                       'groupcompress', False)
+            keys, 'groupcompress', False))
+        stream = vf2.get_record_stream(keys, 'groupcompress', False)
         vf2.writer.end()
         num_records = 0
         # All of the records should be recombined into a single block
@@ -675,39 +665,27 @@
 
     def test__insert_record_stream_no_reuse_block(self):
         vf = self.make_test_vf(True, dir='source')
-        def grouped_stream(revision_ids, first_parents=()):
-            parents = first_parents
-            for revision_id in revision_ids:
-                key = (revision_id,)
-                record = versionedfile.FulltextContentFactory(
-                    key, parents, None,
-                    'some content that is\n'
-                    'identical except for\n'
-                    'revision_id:%s\n' % (revision_id,))
-                yield record
-                parents = (key,)
         # One group, a-d
-        vf.insert_record_stream(grouped_stream(['a', 'b', 'c', 'd']))
+        vf.insert_record_stream(self.grouped_stream([b'a', b'b', b'c', b'd']))
         # Second group, e-h
-        vf.insert_record_stream(grouped_stream(['e', 'f', 'g', 'h'],
-                                               first_parents=(('d',),)))
+        vf.insert_record_stream(self.grouped_stream(
+            [b'e', b'f', b'g', b'h'], first_parents=((b'd',),)))
         vf.writer.end()
-        self.assertEqual(8, len(list(vf.get_record_stream(
-                                        [(r,) for r in 'abcdefgh'],
-                                        'unordered', False))))
+        keys = [(r.encode(),) for r in 'abcdefgh']
+        self.assertEqual(8, len(list(
+            vf.get_record_stream(keys, 'unordered', False))))
         # Now copy the blocks into another vf, and ensure that the blocks are
         # preserved without creating new entries
         vf2 = self.make_test_vf(True, dir='target')
         # ordering in 'groupcompress' order, should actually swap the groups in
         # the target vf, but the groups themselves should not be disturbed.
         list(vf2._insert_record_stream(vf.get_record_stream(
-            [(r,) for r in 'abcdefgh'], 'groupcompress', False),
+            keys, 'groupcompress', False),
             reuse_blocks=False))
         vf2.writer.end()
         # After inserting with reuse_blocks=False, we should have everything in
         # a single new block.
-        stream = vf2.get_record_stream([(r,) for r in 'abcdefgh'],
-                                       'groupcompress', False)
+        stream = vf2.get_record_stream(keys, 'groupcompress', False)
         block = None
         for record in stream:
             if block is None:
@@ -723,7 +701,7 @@
             track_external_parent_refs=True)
         index.scan_unvalidated_index(unvalidated)
         self.assertEqual(
-            frozenset([('missing-parent',)]), index.get_missing_parents())
+            frozenset([(b'missing-parent',)]), index.get_missing_parents())
 
     def test_track_external_parent_refs(self):
         g_index = self.make_g_index('empty', 1, [])
@@ -734,19 +712,19 @@
             add_callback=mod_index.add_nodes,
             track_external_parent_refs=True)
         index.add_records([
-            (('new-key',), '2 10 2 10', [(('parent-1',), ('parent-2',))])])
+            ((b'new-key',), b'2 10 2 10', [((b'parent-1',), (b'parent-2',))])])
         self.assertEqual(
-            frozenset([('parent-1',), ('parent-2',)]),
+            frozenset([(b'parent-1',), (b'parent-2',)]),
             index.get_missing_parents())
 
     def make_source_with_b(self, a_parent, path):
         source = self.make_test_vf(True, dir=path)
-        source.add_lines(('a',), (), ['lines\n'])
+        source.add_lines((b'a',), (), [b'lines\n'])
         if a_parent:
-            b_parents = (('a',),)
+            b_parents = ((b'a',),)
         else:
             b_parents = ()
-        source.add_lines(('b',), b_parents, ['lines\n'])
+        source.add_lines((b'b',), b_parents, [b'lines\n'])
         return source
 
     def do_inconsistent_inserts(self, inconsistency_fatal):
@@ -755,7 +733,7 @@
         for x in range(2):
             source = self.make_source_with_b(x==1, 'source%s' % x)
             target.insert_record_stream(source.get_record_stream(
-                [('b',)], 'unordered', False))
+                [(b'b',)], 'unordered', False))
 
     def test_inconsistent_redundant_inserts_warn(self):
         """Should not insert a record that is already present."""
@@ -768,22 +746,24 @@
             self.do_inconsistent_inserts(inconsistency_fatal=False)
         finally:
             trace.warning = _trace_warning
-        self.assertEqual(["inconsistent details in skipped record: ('b',)"
-                          " ('42 32 0 8', ((),)) ('74 32 0 8', ((('a',),),))"],
-                         warnings)
+        self.assertContainsRe(
+            "\n".join(warnings),
+            r"^inconsistent details in skipped record: \(b?'b',\)"
+            r" \(b?'42 32 0 8', \(\(\),\)\)"
+            r" \(b?'74 32 0 8', \(\(\(b?'a',\),\),\)\)$")
 
     def test_inconsistent_redundant_inserts_raises(self):
         e = self.assertRaises(knit.KnitCorrupt, self.do_inconsistent_inserts,
                               inconsistency_fatal=True)
-        self.assertContainsRe(str(e), "Knit.* corrupt: inconsistent details"
-                              " in add_records:"
-                              " \\('b',\\) \\('42 32 0 8', \\(\\(\\),\\)\\) \\('74 32"
-                              " 0 8', \\(\\(\\('a',\\),\\),\\)\\)")
+        self.assertContainsRe(str(e), r"Knit.* corrupt: inconsistent details"
+                              r" in add_records:"
+                              r" \(b?'b',\) \(b?'42 32 0 8', \(\(\),\)\)"
+                              r" \(b?'74 32 0 8', \(\(\(b?'a',\),\),\)\)")
 
     def test_clear_cache(self):
         vf = self.make_source_with_b(True, 'source')
         vf.writer.end()
-        for record in vf.get_record_stream([('a',), ('b',)], 'unordered',
+        for record in vf.get_record_stream([(b'a',), (b'b',)], 'unordered',
                                            True):
             pass
         self.assertTrue(len(vf._group_cache) > 0)
@@ -908,8 +888,8 @@
                 (read_memo1, groupcompress.GroupCompressBlock()),
                 (read_memo2, groupcompress.GroupCompressBlock())])
         locations = {
-            ('key1',): (read_memo1 + (None, None), None, None, None),
-            ('key2',): (read_memo2 + (None, None), None, None, None)}
+            ('key1',): (read_memo1 + (0, 0), None, None, None),
+            ('key2',): (read_memo2 + (0, 0), None, None, None)}
         batcher = groupcompress._BatchingBlockFetcher(gcvf, locations)
         batcher.add_key(('key1',))
         batcher.add_key(('key2',))
@@ -929,7 +909,7 @@
         gcvf = StubGCVF()
         gcvf._group_cache[read_memo] = fake_block
         locations = {
-            ('key',): (read_memo + (None, None), None, None, None)}
+            ('key',): (read_memo + (0, 0), None, None, None)}
         batcher = groupcompress._BatchingBlockFetcher(gcvf, locations)
         batcher.add_key(('key',))
         self.assertEqual([], list(batcher.yield_factories()))
@@ -942,20 +922,20 @@
 class TestLazyGroupCompress(tests.TestCaseWithTransport):
 
     _texts = {
-        ('key1',): "this is a text\n"
-                   "with a reasonable amount of compressible bytes\n"
-                   "which can be shared between various other texts\n",
-        ('key2',): "another text\n"
-                   "with a reasonable amount of compressible bytes\n"
-                   "which can be shared between various other texts\n",
-        ('key3',): "yet another text which won't be extracted\n"
-                   "with a reasonable amount of compressible bytes\n"
-                   "which can be shared between various other texts\n",
-        ('key4',): "this will be extracted\n"
-                   "but references most of its bytes from\n"
-                   "yet another text which won't be extracted\n"
-                   "with a reasonable amount of compressible bytes\n"
-                   "which can be shared between various other texts\n",
+        (b'key1',): b"this is a text\n"
+                   b"with a reasonable amount of compressible bytes\n"
+                   b"which can be shared between various other texts\n",
+        (b'key2',): b"another text\n"
+                   b"with a reasonable amount of compressible bytes\n"
+                   b"which can be shared between various other texts\n",
+        (b'key3',): b"yet another text which won't be extracted\n"
+                   b"with a reasonable amount of compressible bytes\n"
+                   b"which can be shared between various other texts\n",
+        (b'key4',): b"this will be extracted\n"
+                   b"but references most of its bytes from\n"
+                   b"yet another text which won't be extracted\n"
+                   b"with a reasonable amount of compressible bytes\n"
+                   b"which can be shared between various other texts\n",
     }
     def make_block(self, key_to_text):
         """Create a GroupCompressBlock, filling it with the given texts."""
@@ -983,26 +963,26 @@
     def test_get_fulltexts(self):
         locations, block = self.make_block(self._texts)
         manager = groupcompress._LazyGroupContentManager(block)
-        self.add_key_to_manager(('key1',), locations, block, manager)
-        self.add_key_to_manager(('key2',), locations, block, manager)
+        self.add_key_to_manager((b'key1',), locations, block, manager)
+        self.add_key_to_manager((b'key2',), locations, block, manager)
         result_order = []
         for record in manager.get_record_stream():
             result_order.append(record.key)
             text = self._texts[record.key]
             self.assertEqual(text, record.get_bytes_as('fulltext'))
-        self.assertEqual([('key1',), ('key2',)], result_order)
+        self.assertEqual([(b'key1',), (b'key2',)], result_order)
 
         # If we build the manager in the opposite order, we should get them
         # back in the opposite order
         manager = groupcompress._LazyGroupContentManager(block)
-        self.add_key_to_manager(('key2',), locations, block, manager)
-        self.add_key_to_manager(('key1',), locations, block, manager)
+        self.add_key_to_manager((b'key2',), locations, block, manager)
+        self.add_key_to_manager((b'key1',), locations, block, manager)
         result_order = []
         for record in manager.get_record_stream():
             result_order.append(record.key)
             text = self._texts[record.key]
             self.assertEqual(text, record.get_bytes_as('fulltext'))
-        self.assertEqual([('key2',), ('key1',)], result_order)
+        self.assertEqual([(b'key2',), (b'key1',)], result_order)
 
     def test__wire_bytes_no_keys(self):
         locations, block = self.make_block(self._texts)
@@ -1012,13 +992,13 @@
         # We should have triggered a strip, since we aren't using any content
         stripped_block = manager._block.to_bytes()
         self.assertTrue(block_length > len(stripped_block))
-        empty_z_header = zlib.compress('')
-        self.assertEqual('groupcompress-block\n'
-                         '8\n' # len(compress(''))
-                         '0\n' # len('')
-                         '%d\n'# compressed block len
-                         '%s'  # zheader
-                         '%s'  # block
+        empty_z_header = zlib.compress(b'')
+        self.assertEqual(b'groupcompress-block\n'
+                         b'8\n' # len(compress(''))
+                         b'0\n' # len('')
+                         b'%d\n'# compressed block len
+                         b'%s'  # zheader
+                         b'%s'  # block
                          % (len(stripped_block), empty_z_header,
                             stripped_block),
                          wire_bytes)
@@ -1026,32 +1006,32 @@
     def test__wire_bytes(self):
         locations, block = self.make_block(self._texts)
         manager = groupcompress._LazyGroupContentManager(block)
-        self.add_key_to_manager(('key1',), locations, block, manager)
-        self.add_key_to_manager(('key4',), locations, block, manager)
+        self.add_key_to_manager((b'key1',), locations, block, manager)
+        self.add_key_to_manager((b'key4',), locations, block, manager)
         block_bytes = block.to_bytes()
         wire_bytes = manager._wire_bytes()
         (storage_kind, z_header_len, header_len,
-         block_len, rest) = wire_bytes.split('\n', 4)
+         block_len, rest) = wire_bytes.split(b'\n', 4)
         z_header_len = int(z_header_len)
         header_len = int(header_len)
         block_len = int(block_len)
-        self.assertEqual('groupcompress-block', storage_kind)
+        self.assertEqual(b'groupcompress-block', storage_kind)
         self.assertEqual(34, z_header_len)
         self.assertEqual(26, header_len)
         self.assertEqual(len(block_bytes), block_len)
         z_header = rest[:z_header_len]
         header = zlib.decompress(z_header)
         self.assertEqual(header_len, len(header))
-        entry1 = locations[('key1',)]
-        entry4 = locations[('key4',)]
-        self.assertEqualDiff('key1\n'
-                             '\n'  # no parents
-                             '%d\n' # start offset
-                             '%d\n' # end offset
-                             'key4\n'
-                             '\n'
-                             '%d\n'
-                             '%d\n'
+        entry1 = locations[(b'key1',)]
+        entry4 = locations[(b'key4',)]
+        self.assertEqualDiff(b'key1\n'
+                             b'\n'  # no parents
+                             b'%d\n' # start offset
+                             b'%d\n' # end offset
+                             b'key4\n'
+                             b'\n'
+                             b'%d\n'
+                             b'%d\n'
                              % (entry1[0], entry1[1],
                                 entry4[0], entry4[1]),
                             header)
@@ -1061,10 +1041,10 @@
     def test_from_bytes(self):
         locations, block = self.make_block(self._texts)
         manager = groupcompress._LazyGroupContentManager(block)
-        self.add_key_to_manager(('key1',), locations, block, manager)
-        self.add_key_to_manager(('key4',), locations, block, manager)
+        self.add_key_to_manager((b'key1',), locations, block, manager)
+        self.add_key_to_manager((b'key4',), locations, block, manager)
         wire_bytes = manager._wire_bytes()
-        self.assertStartsWith(wire_bytes, 'groupcompress-block\n')
+        self.assertStartsWith(wire_bytes, b'groupcompress-block\n')
         manager = groupcompress._LazyGroupContentManager.from_bytes(wire_bytes)
         self.assertIsInstance(manager, groupcompress._LazyGroupContentManager)
         self.assertEqual(2, len(manager._factories))
@@ -1074,7 +1054,7 @@
             result_order.append(record.key)
             text = self._texts[record.key]
             self.assertEqual(text, record.get_bytes_as('fulltext'))
-        self.assertEqual([('key1',), ('key4',)], result_order)
+        self.assertEqual([(b'key1',), (b'key4',)], result_order)
 
     def test__check_rebuild_no_changes(self):
         block, manager = self.make_block_and_full_manager(self._texts)
@@ -1085,14 +1065,14 @@
         locations, block = self.make_block(self._texts)
         manager = groupcompress._LazyGroupContentManager(block)
         # Request just the first key, which should trigger a 'strip' action
-        self.add_key_to_manager(('key1',), locations, block, manager)
+        self.add_key_to_manager((b'key1',), locations, block, manager)
         manager._check_rebuild_block()
         self.assertIsNot(block, manager._block)
         self.assertTrue(block._content_length > manager._block._content_length)
         # We should be able to still get the content out of this block, though
         # it should only have 1 entry
         for record in manager.get_record_stream():
-            self.assertEqual(('key1',), record.key)
+            self.assertEqual((b'key1',), record.key)
             self.assertEqual(self._texts[record.key],
                              record.get_bytes_as('fulltext'))
 
@@ -1100,12 +1080,12 @@
         locations, block = self.make_block(self._texts)
         manager = groupcompress._LazyGroupContentManager(block)
         # Request a small key in the middle should trigger a 'rebuild'
-        self.add_key_to_manager(('key4',), locations, block, manager)
+        self.add_key_to_manager((b'key4',), locations, block, manager)
         manager._check_rebuild_block()
         self.assertIsNot(block, manager._block)
         self.assertTrue(block._content_length > manager._block._content_length)
         for record in manager.get_record_stream():
-            self.assertEqual(('key4',), record.key)
+            self.assertEqual((b'key4',), record.key)
             self.assertEqual(self._texts[record.key],
                              record.get_bytes_as('fulltext'))
 
@@ -1145,8 +1125,8 @@
             get_compressor_settings=lambda: dict(max_bytes_to_index=32))
         gc = manager._make_group_compressor()
         self.assertEqual(32, gc._delta_index._max_bytes_to_index)
-        self.add_key_to_manager(('key3',), locations, old_block, manager)
-        self.add_key_to_manager(('key4',), locations, old_block, manager)
+        self.add_key_to_manager((b'key3',), locations, old_block, manager)
+        self.add_key_to_manager((b'key4',), locations, old_block, manager)
         action, last_byte, total_bytes = manager._check_rebuild_action()
         self.assertEqual('rebuild', action)
         manager._rebuild_block()
@@ -1173,14 +1153,14 @@
 
     def test_check_is_well_utilized_mixed_keys(self):
         texts = {}
-        f1k1 = ('f1', 'k1')
-        f1k2 = ('f1', 'k2')
-        f2k1 = ('f2', 'k1')
-        f2k2 = ('f2', 'k2')
-        texts[f1k1] = self._texts[('key1',)]
-        texts[f1k2] = self._texts[('key2',)]
-        texts[f2k1] = self._texts[('key3',)]
-        texts[f2k2] = self._texts[('key4',)]
+        f1k1 = (b'f1', b'k1')
+        f1k2 = (b'f1', b'k2')
+        f2k1 = (b'f2', b'k1')
+        f2k2 = (b'f2', b'k2')
+        texts[f1k1] = self._texts[(b'key1',)]
+        texts[f1k2] = self._texts[(b'key2',)]
+        texts[f2k1] = self._texts[(b'key3',)]
+        texts[f2k2] = self._texts[(b'key4',)]
         block, manager = self.make_block_and_full_manager(texts)
         self.assertFalse(manager.check_is_well_utilized())
         manager._full_enough_block_size = block._content_length
@@ -1194,14 +1174,14 @@
         locations, block = self.make_block(self._texts)
         manager = groupcompress._LazyGroupContentManager(block)
         manager._full_enough_block_size = block._content_length
-        self.add_key_to_manager(('key1',), locations, block, manager)
-        self.add_key_to_manager(('key2',), locations, block, manager)
+        self.add_key_to_manager((b'key1',), locations, block, manager)
+        self.add_key_to_manager((b'key2',), locations, block, manager)
         # Just using the content from key1 and 2 is not enough to be considered
         # 'complete'
         self.assertFalse(manager.check_is_well_utilized())
         # However if we add key3, then we have enough, as we only require 75%
         # consumption
-        self.add_key_to_manager(('key4',), locations, block, manager)
+        self.add_key_to_manager((b'key4',), locations, block, manager)
         self.assertTrue(manager.check_is_well_utilized())
 
 
@@ -1224,4 +1204,3 @@
         self.assertEqual("_GCBuildDetails(('INDEX', 10, 20, 0, 5),"
                          " (('parent1',), ('parent2',)))",
                          repr(bd))
-                    

=== modified file 'breezy/tests/test_rename_map.py'
--- breezy/tests/test_rename_map.py	2017-05-22 00:56:52 +0000
+++ breezy/tests/test_rename_map.py	2017-11-11 18:32:23 +0000
@@ -200,3 +200,18 @@
         notes = self.captureNotes(RenameMap.guess_renames, tree,
                                   dry_run=False)[0]
         self.assertEqual('file => file2', ''.join(notes))
+
+    def test_guess_rename_handles_new_directories(self):
+        """When a file was moved into a new directory."""
+        tree = self.make_branch_and_tree('.')
+        tree.lock_write()
+        #self.addCleanup(tree.unlock)
+        self.build_tree(['file'])
+        tree.add('file', 'file-id')
+        tree.commit('Added file')
+        os.mkdir('folder')
+        os.rename('file', 'folder/file2')
+        notes = self.captureNotes(RenameMap.guess_renames, tree)[0]
+        self.assertEqual('file => folder/file2', ''.join(notes))
+
+        tree.unlock()

=== modified file 'doc/developers/HACKING.txt'
--- doc/developers/HACKING.txt	2017-07-30 16:59:50 +0000
+++ doc/developers/HACKING.txt	2017-11-11 18:32:23 +0000
@@ -1,14 +1,14 @@
 ======================
-Bazaar Developer Guide
+Breezy 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.
+This document describes the Breezy internals and the development process.
+It's meant for people interested in developing Breezy, and some parts will
+also be useful to people developing Breezy 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
+the Breezy 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
@@ -17,7 +17,7 @@
 Getting Started
 ###############
 
-Exploring the Bazaar Platform
+Exploring the Breezy Platform
 =============================
 
 Before making changes, it's a good idea to explore the work already
@@ -26,13 +26,13 @@
 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:
+overall Breezy 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
+* The Breezy product family on Launchpad - https://launchpad.net/breezy
 
-* Bug Tracker for the core product - https://bugs.launchpad.net/bzr/
+* Bug Tracker for the core product - https://bugs.launchpad.net/brz/
 
 If nothing else, perhaps you'll find inspiration in how other developers
 have solved their challenges.
@@ -41,17 +41,17 @@
 =======================
 
 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
+flag. For instance running ``brz -Devil commit -m "test"`` will log a backtrace
+to the Breezy log file for every method call which triggers a slow or non-scalable
+part of the breezy 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
+There is a very active community around Breezy. Mostly we meet on IRC
+(#bzr on irc.freenode.net) and on the mailing list. To join the Breezy
 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
@@ -70,15 +70,15 @@
 friendly, helpful and always keen to welcome newcomers.
 
 
-Bazaar Development in a Nutshell
+Breezy 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
+One of the fun things about working on a version control system like Breezy 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.
+to Breezy.  More detailed instructions are in the following sections.
 
 Making the change
 -----------------
@@ -87,20 +87,20 @@
 copy of bzr.dev?`_.)
 ::
 
- $ bzr init-repo ~/bzr
+ $ brz init-repo ~/bzr
  $ cd ~/bzr
- $ bzr branch lp:bzr bzr.dev
+ $ brz branch lp:brz bzr.dev
 
 Now make your own branch::
 
- $ bzr branch bzr.dev 123456-my-bugfix
+ $ brz 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
+Breezy project.  The documentation is in the `doc/` subdirectory of the Breezy
 source tree.
 
 When you are done, make sure that you commit your last set of changes as well!
@@ -110,20 +110,20 @@
 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
+The Breezy developers use Launchpad to further enable a truly distributed
+style of development.  Anyone can propose a branch for merging into the Breezy
 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::
+Breezy::
 
-  $ bzr push lp:~<your_lp_username>/bzr/meaningful_name_here
+  $ brz 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
+the Breezy 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.
+your changes off to the Breezy developers for review and merging.
 
 Alternatively, after pushing you can use the ``lp-propose`` command to 
 create the merge proposal.
@@ -164,19 +164,19 @@
 
 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``.
+- You can use that copy of bzr.dev as your main brz executable, and keep it
+  up-to-date using ``brz pull``.
 - Certain operations are faster, and can be done when offline.  For example:
 
-  - ``bzr bundle``
-  - ``bzr diff -r ancestor:...``
-  - ``bzr merge``
+  - ``brz bundle``
+  - ``brz diff -r ancestor:...``
+  - ``brz 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
+    $ brz branch bzr.dev additional_fixes
     $ cd additional_fixes # hack, hack, hack
 
 
@@ -210,10 +210,10 @@
 
 
 
-Preparing a Sandbox for Making Changes to Bazaar
+Preparing a Sandbox for Making Changes to Breezy
 ================================================
 
-Bazaar supports many ways of organising your work. See
+Breezy supports many ways of organising your work. See
 http://wiki.bazaar.canonical.com/SharedRepositoryLayouts for a summary of the
 popular alternatives.
 
@@ -224,10 +224,10 @@
 * create a local copy of the main development branch (bzr.dev) by using
   this command::
 
-    bzr branch lp:bzr bzr.dev
+    brz branch lp:brz bzr.dev
 
 * keep your copy of bzr.dev pristine (by not developing in it) and keep
-  it up to date (by using bzr pull)
+  it up to date (by using brz pull)
 
 * create a new branch off your local bzr.dev copy for each issue
   (bug or feature) you are working on.
@@ -247,17 +247,17 @@
 Some of the key files in this directory are:
 
 bzr
-    The command you run to start Bazaar itself.  This script is pretty
+    The command you run to start Breezy 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
+    This file covers a brief introduction to Breezy 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
+    Installs Breezy system-wide or to your home directory.  To perform
+    development work on Breezy it is not required to run this file - you
+    can simply run the Breezy 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
@@ -268,35 +268,35 @@
 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.
+    Breezy.
 
 doc
-    Holds documentation on a whole range of things on Bazaar from the
-    origination of ideas within the project to information on Bazaar
+    Holds documentation on a whole range of things on Breezy from the
+    origination of ideas within the project to information on Breezy
     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.
+    Documentation specifically targeted at Breezy and plugin developers.
     (Including this document.)
 
 doc/en/release-notes/
 
-    Detailed changes in each Bazaar release (there is one file by series:
+    Detailed changes in each Breezy 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
+    High-level summaries of changes in each Breezy 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
+See also the `Breezy Architectural Overview
 <http://doc.bazaar.canonical.com/developers/overview.html>`_.
 
 
@@ -307,7 +307,7 @@
 ===================
 
 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
+release of Breezy 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
@@ -368,68 +368,22 @@
 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
+Breezy 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
+then brz 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
+If you send a SIGQUIT or SIGBREAK signal to brz 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
@@ -446,7 +400,7 @@
 Debug Flags
 ===========
 
-Bazaar accepts some global options starting with ``-D`` such as
+Breezy 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
@@ -454,7 +408,7 @@
 
 Debug flags may have effects other than just emitting trace messages.
 
-Run ``bzr help global-options`` to see them all.
+Run ``brz 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.  ``~/.config/breezy/breezy.conf``.  (Note
@@ -478,7 +432,7 @@
 Unicode and Encoding Support
 ============================
 
-This section discusses various techniques that Bazaar uses to handle
+This section discusses various techniques that Breezy uses to handle
 characters that are outside the ASCII set.
 
 ``Command.outf``
@@ -498,15 +452,15 @@
     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
+    For example: ``brz 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``
+    For example: ``brz ls`` is designed to be used with shell scripting. One
+    use would be ``brz 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.
@@ -514,7 +468,7 @@
   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
+    For example: ``brz diff`` needs to translate Unicode paths, but should
     not change the exact text of the contents of the files.
 
 
@@ -540,7 +494,7 @@
  * User with C compiler
  * Developers
 
-The recommended way to install bzr is to have a C compiler so that the
+The recommended way to install Breezy 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.
 
@@ -572,14 +526,14 @@
 What is a Core Developer?
 -------------------------
 
-While everyone in the Bazaar community is welcome and encouraged to
+While everyone in the Breezy 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>`_)
+* managing releases (see `Releasing Breezy <http://doc.bazaar.canonical.com/developers/releasing.html>`_)
 
 .. note::
   Removing barriers to community participation is a key reason for adopting

=== added file 'doc/developers/branding.txt'
--- doc/developers/branding.txt	1970-01-01 00:00:00 +0000
+++ doc/developers/branding.txt	2017-11-11 18:32:23 +0000
@@ -0,0 +1,14 @@
+Breezy branding
+===============
+
+``Breezy`` (with that capitalisation) is the name of the project and our current implementation.
+
+``breezy`` is the name of the Python package.
+
+``brz`` is the command line tool.
+
+``Bazaar`` is the name of the old project, as well as the name of the formats.
+
+``bzr`` is the name of the old binary.
+
+Slogan: "Like bzr, but with more b-s in"

=== modified file 'doc/developers/bug-handling.txt'
--- doc/developers/bug-handling.txt	2011-05-04 10:45:00 +0000
+++ doc/developers/bug-handling.txt	2017-11-11 18:32:23 +0000
@@ -1,46 +1,46 @@
 ***********************
-Tracking Bugs in Bazaar
+Tracking Bugs in Breezy
 ***********************
 
-This document describes the bug-tracking processes for developing Bazaar
-itself.  Bugs in Bazaar are recorded in Launchpad.
+This document describes the bug-tracking processes for developing Breezy
+itself.  Bugs in Breezy 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.
+* `Breezy Developer Documents <index.html>`_.
+
+* `The Breezy Development Cycle <cycle.html>`_.
+
+* `The Breezy User Guide <../en/user-guide/index.html>`_ -- for
+  information on integrating Breezy 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>`_.
+* `Breezy bugs home page <https://bugs.launchpad.net/brz>`_.
+
+* `Critical bugs <https://bugs.launchpad.net/brz/+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/brz/+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=>`_.
+  <https://bugs.launchpad.net/brz/+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>`_.
+* `Most commonly duplicated bugs <http://tinyurl.com/brz-bugs-by-dupes>`_.
 
 
 Generalities
 ************
 
-Anyone involved with Bazaar is welcome to contribute to managing our bug
+Anyone involved with Breezy 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
+When you file a bug as a Breezy 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
@@ -143,17 +143,16 @@
     progress on the bug without that information.  The bug will expire if
     it remains in this state for two months.
 Confirmed
+    This bug has been confirmed by at least one other person (developer or otherwise).
+Triaged
     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
+    You don't have to reproduce the bug to mark it Triaged.  (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.  
-    
+    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
@@ -169,15 +168,15 @@
     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.  
-    
+    The fix for this bug is now in the Breezy branch that this task is for.
+    The branch for the default task on a bug is trunk.
+
     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. 
-    
+    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
@@ -191,14 +190,14 @@
 **************
 
 Critical
-    This is a serious bug that could cause data loss, stop bzr being
+    This is a serious bug that could cause data loss, stop Breezy 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
+    Breezy.  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.
@@ -228,7 +227,7 @@
 ***************
 
 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
+<https://bugs.launchpad.net/brz/+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
@@ -289,7 +288,7 @@
     bugs for causes of VFS methods of the smart server
 
 launchpad
-    bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
+    bugs about interactions with launchpad (typically this means breezy.plugins.launchpad).
 
 locale
     problems using locales other than English
@@ -304,7 +303,7 @@
     bugs about performance problems.
 
 regression
-    bugs which represent an aspect of bzr becoming accidentally less good than it was.
+    bugs which represent an aspect of Breezy becoming accidentally less good than it was.
 
 test
     needs changes to the test framework
@@ -313,18 +312,18 @@
     virtual filesystem for HTTP, SFTP, etc.
 
 trivial
-    should be very easy to fix (10-20 minutes) and easily landed: typically 
+    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.
+    bugs relating to the Breezy user interface, e.g. confusing error messages.
 
 win32
-    bugs that mainly affects Windows. Also there is cygwin and win98 tags for 
+    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. 
+<https://bugs.launchpad.net/brz/+bugs>.  As of September 2008 the
+list is on the right.
 
 .. vim: ft=rst

=== modified file 'doc/developers/case-insensitive-file-systems.txt'
--- doc/developers/case-insensitive-file-systems.txt	2011-11-24 17:24:21 +0000
+++ doc/developers/case-insensitive-file-systems.txt	2017-11-11 18:32:23 +0000
@@ -66,7 +66,7 @@
   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
+  destination), the argument will be used as specified.  Breezy 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.)

=== modified file 'doc/developers/check.txt'
--- doc/developers/check.txt	2010-11-12 22:43:38 +0000
+++ doc/developers/check.txt	2017-11-11 18:32:23 +0000
@@ -10,7 +10,7 @@
 
 * 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
+* Look for and report on recorded-data issues where previous Breezy'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

=== modified file 'doc/developers/code-review.txt'
--- doc/developers/code-review.txt	2011-06-06 08:24:45 +0000
+++ doc/developers/code-review.txt	2017-11-11 18:32:23 +0000
@@ -3,7 +3,7 @@
 
 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 
+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.
 
@@ -11,12 +11,12 @@
 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.  
+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 
+From late 2009 on, we do all our code reviews through Launchpad's
 merge proposal interface.
 
 
@@ -85,7 +85,7 @@
 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
+From <https://code.launchpad.net/brz/+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.
@@ -100,5 +100,5 @@
 
 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 
+way to start this off is by running the ``feed-pqm`` script from
 <https://launchpad.net/hydrazine/>.

=== modified file 'doc/developers/code-style.txt'
--- doc/developers/code-style.txt	2017-05-21 12:29:48 +0000
+++ doc/developers/code-style.txt	2017-11-11 18:32:23 +0000
@@ -62,7 +62,7 @@
 character on the following line.  This makes it easier to add new items in
 future::
 
-    from bzrlib.goo import (
+    from breezy.goo import (
         jam,
         jelly,
         marmalade,
@@ -98,7 +98,7 @@
 ``**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.  
+(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
@@ -133,7 +133,7 @@
   they don't run inside hot functions.
 
 * Module names should always be given fully-qualified,
-  i.e. ``bzrlib.hashcache`` not just ``hashcache``.
+  i.e. ``breezy.hashcache`` not just ``hashcache``.
 
 
 Naming
@@ -141,7 +141,7 @@
 
 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
+public not just across modules but to programmers using breezy as an
 API.
 
 We prefer class names to be concatenated capital words (``TestCase``)
@@ -193,7 +193,7 @@
    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
@@ -201,7 +201,7 @@
 
 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``
+generally uninteresting compared to the original exception.  ``breezy``
 has some facilities you can use to mitigate this.
 
 * In ``Command`` subclasses, prefer the ``add_cleanup`` method to using
@@ -215,14 +215,14 @@
   acquire/release) because there isn't a large block of code separating
   them.
 
-* Use the ``only_raises`` decorator (from ``bzrlib.decorators``) when
+* Use the ``only_raises`` decorator (from ``breezy.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
+  ``breezy.cleanup`` anywhere else you have a ``finally`` block that
   might fail.
 
 
@@ -273,25 +273,25 @@
 Lazy Imports
 ============
 
-To make startup time faster, we use the ``bzrlib.lazy_import`` module to
+To make startup time faster, we use the ``breezy.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
+  from breezy.lazy_import import lazy_import
   lazy_import(globals(), """
   import os
   import subprocess
   import sys
   import time
 
-  from bzrlib import (
+  from breezy import (
      errors,
      transport,
      revision as _mod_revision,
      )
-  import bzrlib.transport
-  import bzrlib.xml5
+  import breezy.transport
+  import breezy.xml5
   """)
 
 At this point, all of these exist as a ``ImportReplacer`` object, ready to
@@ -330,7 +330,7 @@
 
 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
+to the null revision, please use ``breezy.revision.NULL_REVISION``.  Old
 code sometimes uses ``None`` for the null revision, but this practice is
 being phased out.
 
@@ -460,12 +460,12 @@
 Portability Tips
 ================
 
-The ``bzrlib.osutils`` module has many useful helper functions, including
+The ``breezy.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.
+Use ``breezy.osutils.rmtree`` instead.
 
 Using the ``open(..).read(..)`` or ``open(..).write(..)`` style chaining
 of methods for reading or writing file content relies on garbage collection
@@ -489,7 +489,7 @@
  * 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
+ * In all other cases, prefer ``breezy.pyutils.get_named_object`` to the
    built-in ``__import__``.  ``__import__`` has some subtleties and
    unintuitive behaviours that make it hard to use correctly.
 

=== modified file 'doc/developers/colocated-branches.txt'
--- doc/developers/colocated-branches.txt	2010-04-12 15:28:32 +0000
+++ doc/developers/colocated-branches.txt	2017-11-11 18:32:23 +0000
@@ -41,21 +41,21 @@
 UI Changes
 ~~~~~~~~~~
 
-Bazaar URLs need to have some way to address colocated branches in 
-directories that contain multiple branches. 
+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 
+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 
+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:
 
@@ -64,26 +64,26 @@
 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 
+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 
+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 
+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 
+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:
@@ -96,15 +96,15 @@
  * BranchFormat.initialise()
  * BranchFormat.open()
 
-A new BzrDir.list_branches() method will return all colocated branches 
-present in a control directory. 
+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 
+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 
+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
@@ -117,7 +117,7 @@
 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 
+BzrDirMeta2 though. An example of this is implemented in the
 lp:bzr-colocated plugin
 
 Further integration

=== renamed file 'doc/developers/new-config-rationale.txt' => 'doc/developers/config-rationale.txt'
--- doc/developers/new-config-rationale.txt	2017-07-31 00:12:06 +0000
+++ doc/developers/config-rationale.txt	2017-11-11 18:32:23 +0000
@@ -6,12 +6,12 @@
 ====
 
 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 ;).
+breezy, 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
+Many parts of ``breezy`` 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.
@@ -28,7 +28,7 @@
 Current issues
 ==============
 
-* Many parts of ``bzrlib`` declare constants and there is no way for the
+* Many parts of ``breezy`` 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
@@ -158,7 +158,7 @@
   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
+  interpolation feature, the ``breezy`` 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
@@ -218,7 +218,7 @@
 
 The option name space is organized by topic:
 
-* bzrlib options are grouped by topic (``branch``, ``tree``, ``repo``)
+* breezy 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)
@@ -263,7 +263,7 @@
 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.
+where some parameters are set by ``breezy`` at runtime.
 
 Since option values are text-only, and to avoid clashing with other option
 expansion (also known as interpolation) syntaxes, references are enclosed
@@ -276,7 +276,7 @@
 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
+``breezy`` or plugins can define references that can be expanded without
 being existing configuration options::
 
   diff_command={cmd} {cmd_opts} {file_a} {file_b}

=== modified file 'doc/developers/content-filtering.txt'
--- doc/developers/content-filtering.txt	2010-12-02 09:46:15 +0000
+++ doc/developers/content-filtering.txt	2017-11-11 18:32:23 +0000
@@ -37,7 +37,7 @@
 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.)
+file they're working on.  (See ``breezy.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
@@ -46,7 +46,7 @@
 Conventions
 ***********
 
-bzrlib interfaces that aren't explicitly specified to deal with the
+breezy 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.
 
@@ -142,6 +142,6 @@
 
 * `Developer Documentation <index.html>`_
 
-* ``bzrlib.filters``
+* ``breezy.filters``
 
 .. vim: ft=rst tw=72

=== modified file 'doc/developers/contribution-quickstart.txt'
--- doc/developers/contribution-quickstart.txt	2011-08-11 05:48:38 +0000
+++ doc/developers/contribution-quickstart.txt	2017-11-11 18:32:23 +0000
@@ -88,9 +88,9 @@
 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
+``breezy.tests.blackbox`` and for library code in ``breezy.tests``.  For
 functions on an interface for which there are multiple implementations,
-like `Transport`, look in ``bzrlib.tests.per_transport``.
+like `Transport`, look in ``breezy.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.

=== modified file 'doc/developers/cycle.txt'
--- doc/developers/cycle.txt	2011-01-03 23:48:17 +0000
+++ doc/developers/cycle.txt	2017-11-11 18:32:23 +0000
@@ -1,14 +1,13 @@
 *********************
-Bazaar Release Cycles
+Breezy Release Cycles
 *********************
 
-:status: Current policy, as of 2010-10.
-:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
+:status: Current policy, as of 2017-11.
 
 
 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
+Breezy 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
@@ -16,7 +15,7 @@
 
 See also:
 
-* `Bazaar Developer Document Catalog <index.html>`_
+* `Breezy Developer Document Catalog <index.html>`_
 
 * `Releasing Bazaar <releasing.html>`_ -- the process for actually making
   a release or release candidate.
@@ -25,7 +24,7 @@
 The Process
 ************
 
-Bazaar will make a major release every six months, which will be supported at
+Breezy 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
@@ -193,18 +192,18 @@
 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.
+of breezy, 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
+In return we expect more freedom to change and cleanup breezy 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
+Discussion of plugins here includes programs that import and use breezy
 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.
@@ -251,7 +250,7 @@
 
 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
+source.  (For example, we will not change the breezy library name from one
 release to the next.)
 
 The issue already exists with people who may want to use for example the

=== modified file 'doc/developers/development-repo.txt'
--- doc/developers/development-repo.txt	2010-08-13 19:08:57 +0000
+++ doc/developers/development-repo.txt	2017-11-11 18:32:23 +0000
@@ -200,17 +200,17 @@
    ``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
+   ``breezy.repofmt``. You probably want to reproduce the current
+   development format from ``breezy.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
+    1. ``breezy/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
+    2. ``breezy/workingtree.py``, ``breezy/branch.py``,
+       ``breezy/repository.py``, each one maintains a direct list of
        their respective formats.
 
     3. For repositories, you also need to update the InterKnit1and2
@@ -218,11 +218,11 @@
        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
+       ``breezy/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
+   to find these is a grep for Development in breezy - 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

=== modified file 'doc/developers/documenting-changes.txt'
--- doc/developers/documenting-changes.txt	2010-10-14 21:23:08 +0000
+++ doc/developers/documenting-changes.txt	2017-11-11 18:32:23 +0000
@@ -7,7 +7,7 @@
 
 Changing existing behavior
   If the change will break existing command lines, or break
-  interoperability with other versions of Bazaar, mention this in 
+  interoperability with other versions of Breezy, mention this in
   "External Compatibility Breaks" in NEWS, and also in "What's New".
 
 Adding a new feature, function or option
@@ -17,7 +17,7 @@
 
 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 
+  "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.
 
@@ -40,8 +40,8 @@
   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 
+  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.
 

=== modified file 'doc/developers/ec2.txt'
--- doc/developers/ec2.txt	2010-12-16 06:24:14 +0000
+++ doc/developers/ec2.txt	2017-11-11 18:32:23 +0000
@@ -1,5 +1,5 @@
 =========================
-Bazaar Windows EC2 Server
+Breezy Windows EC2 Server
 =========================
 
 We have an Amazon EC2 virtual machine called Desolation_ for
@@ -10,7 +10,7 @@
 
 See also:
 
-* `Bazaar Developer Documentation Catalog <index.html>`_.
+* `Breezy Developer Documentation Catalog <index.html>`_.
 
 
 .. _Desolation: http://en.wikipedia.org/wiki/Desolation_Island
@@ -31,7 +31,7 @@
 * 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
+* 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.
@@ -92,7 +92,7 @@
 Preparation
 -----------
 
-* Be in the bzr core team.  If you are interested in helping with
+* Be in the brz core team.  If you are interested in helping with
   Windows packaging, testing or development just ask.
 
 * Install the

=== modified file 'doc/developers/implementation-notes.txt'
--- doc/developers/implementation-notes.txt	2010-07-07 11:21:19 +0000
+++ doc/developers/implementation-notes.txt	2017-11-11 18:32:23 +0000
@@ -10,7 +10,7 @@
    lca_tree_merging
 
 
-* `BTree Index Prefetch <btree_index_prefetch.html>`_ |--| How bzr decides
+* `BTree Index Prefetch <btree_index_prefetch.html>`_ |--| How Breezy decides
   to pre-read extra nodes in the btree index.
 
 * `Computing last_modified values <last-modified.html>`_ for inventory

=== modified file 'doc/developers/index-plain.txt'
--- doc/developers/index-plain.txt	2012-02-29 13:55:25 +0000
+++ doc/developers/index-plain.txt	2017-11-11 18:32:23 +0000
@@ -1,5 +1,5 @@
 =================================
-Bazaar Developer Document Catalog
+Breezy Developer Document Catalog
 =================================
 
 
@@ -15,45 +15,42 @@
   (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.
+* `Integrating with Breezy <http://wiki.bazaar.canonical.com/Integrating_with_Bazaar>`_
+  (wiki) |--| a guide for writing Python programs that work with Breezy.
 
 * `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.
+* `Testing <testing.html>`_ |--| Guide to writing tests for Breezy.
 
 * `Code Review <code-review.html>`_.
 
-* `Bazaar Code Style Guide <code-style.html>`_.
+* `Breezy 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)
+  |--| specific advice on writing Breezy 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.
+* `Releasing Breezy <releasing.html>`_ |--|
+  Checklist to make a release of Breezy.
+
+* `Managing the Breezy PPA <ppa.html>`_ |--| Packaging Breezy for Ubuntu.
 
 * `Giving back <http://wiki.bazaar.canonical.com/BzrGivingBack>`_ (wiki) |--| How to get
-  your changes to Bazaar integrated into a release.
+  your changes to Breezy integrated into a release.
 
 * `Profiling notes <profiling.html>`_ |--| Instructions on how to profile
-  bzr code and visualize the results.
+  brz 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
+* `Tracking Bugs in Breezy <bug-handling.html>`_ |--| How we use the bug
   tracker.
 
 Architecture overviews
@@ -66,13 +63,13 @@
 =====
 
 * `Performance roadmap <performance-roadmap.html>`_ |--| The roadmap
-  for fixing performance in bzr over the next few releases.
+  for fixing performance in brz 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
+* `Breezy Windows Shell Extension Options <tortoise-strategy.html>`_ |--|
+  Implementation strategy for Breezy Windows Shell Extensions, aka
   TortoiseBzr.
 
 * `CHK Optimized index <improved_chk_index.html>`_
@@ -88,10 +85,10 @@
 * `Authentication ring <authentication-ring.html>`_ |--| Configuring
   authentication.
 
-* `Bundles <bundles.html>`_ |--| All about bzr bundles.
+* `Bundles <bundles.html>`_ |--| All about brz bundles.
 
 * `Container format <container-format.html>`_ |--| Notes on a container format
-  for streaming and storing Bazaar data.
+  for streaming and storing Breezy data.
 
 * `Groupcompress <groupcompress-design.html>`_ |--| Notes on the compression
   technology used in CHK repositories.
@@ -114,8 +111,8 @@
 * `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
+* `Breezy and case-insensitive file systems <case-insensitive-file-systems.html>`_
+  |--| How Breezy operates on case-insensitive file systems such as commonly
   found on Windows, USB sticks, etc.
 
 * `Development repository formats <development-repo.html>`_ |--| How to
@@ -132,7 +129,7 @@
 Implementation notes
 ====================
 
-* `BTree Index Prefetch <btree_index_prefetch.html>`_ |--| How bzr decides
+* `BTree Index Prefetch <btree_index_prefetch.html>`_ |--| How brz decides
   to pre-read extra nodes in the btree index.
 
 * `Computing last_modified values <last-modified.html>`_ for inventory
@@ -148,7 +145,7 @@
 
 * `dirstate <dirstate.html>`_ |--| An observation re. the dirstate file
 
-* `"bzr update" performance analysis <update.html>`_ |--| "bzr update"
+* `"brz update" performance analysis <update.html>`_ |--| "brz update"
   performance analysis
 
 

=== modified file 'doc/developers/index.txt'
--- doc/developers/index.txt	2012-02-29 13:55:25 +0000
+++ doc/developers/index.txt	2017-11-11 18:32:23 +0000
@@ -1,5 +1,5 @@
 =================================
-Bazaar Developer Document Catalog
+Breezy Developer Document Catalog
 =================================
 
 
@@ -12,13 +12,12 @@
    contribution-quickstart
 
 
-Working on Bazaar
+Working on Breezy
 =================
 
 .. toctree::
    :maxdepth: 1
 
-   cycle
    profiling
    bug-handling
    HACKING
@@ -27,7 +26,7 @@
    code-style
    documenting-changes
 
-* `Contributing to Bazaar Documentation <http://wiki.bazaar.canonical.com/ContributingToTheDocs>`_ (wiki)
+* `Contributing to Breezy Documentation <http://wiki.bazaar.canonical.com/ContributingToTheDocs>`_ (wiki)
 
 
 Architecture overviews
@@ -61,7 +60,7 @@
    overview
    integration
 
-* `Writing plugins for Bazaar <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_ (web link)
+* `Writing plugins for Breezy <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_ (web link)
 
 * `bzrlib API reference <http://people.canonical.com/~mwh/bzrlibapi/>`_
   (web link)
@@ -83,8 +82,8 @@
 Licence
 ============
 
-Copyright 2005-2011 Canonical Ltd. Bazaar is free software, and you
-may use, modify and redistribute both Bazaar and this document under
+Copyright 2005-2011 Canonical Ltd. Breezy is free software, and you
+may use, modify and redistribute both Breezy and this document under
 the terms of the GNU General Public License version 2 or later.  See
 <http://www.gnu.org/licenses/>.
 

=== modified file 'doc/developers/indices.txt'
--- doc/developers/indices.txt	2007-07-15 15:40:37 +0000
+++ doc/developers/indices.txt	2017-11-11 18:32:23 +0000
@@ -7,7 +7,7 @@
 
 :Date: 2007-07-14
 
-This document describes the indexing facilities within bzrlib.
+This document describes the indexing facilities within breezy.
 
 
 .. contents::
@@ -33,7 +33,7 @@
 Overview
 ========
 
-bzr is moving to a write-once model for repository storage in order to
+Breezy 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
@@ -98,7 +98,7 @@
 
 ``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
+graph index for Breezy. 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.

=== modified file 'doc/developers/integration.txt'
--- doc/developers/integration.txt	2017-06-10 00:17:06 +0000
+++ doc/developers/integration.txt	2017-11-11 18:32:23 +0000
@@ -1,9 +1,9 @@
 =======================
-Integrating with Bazaar
+Integrating with Breezy
 =======================
 
 This document provides some general observations on integrating with
-Bazaar and some recipes for typical tasks.  It is intended to be useful to
+Breezy 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.
@@ -11,26 +11,26 @@
 
 
 
-Starting with bzrlib
+Starting with breezy
 ====================
 
 Within bzr
 ----------
 
-When using bzrlib within the ``bzr`` program (for instance as a bzr
-plugin), bzrlib's global state is already available for use.
+When using breezy within the ``bzr`` program (for instance as a bzr
+plugin), breezy'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
+To use breezy outside of ``bzr`` some global state needs to be setup.
+breezy 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``. 
+``breezy.initialize``. 
 
-This returns a context manager within which bzrlib functions will work
-correctly. See the pydoc for ``bzrlib.initialize`` for more information. 
+This returns a context manager within which breezy functions will work
+correctly. See the pydoc for ``breezy.initialize`` for more information. 
 (You can get away without entering the context manager, because the setup
 work happens directly from ``initialize``.)
 
@@ -39,7 +39,7 @@
 
   # 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 = breezy.initialize()
   library_state.__enter__()
   try:
       pass
@@ -53,22 +53,22 @@
 
 To run command-line commands in-process::
 
-  from bzrlib.commands import get_command
+  from breezy.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`.
+elsewhere through the parameters to `breezy.initialize`.
 
 
 Manipulating the Working Tree
 =============================
-Most objects in Bazaar are in files, named after the class they contain.
+Most objects in Breezy 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
+  from breezy import workingtree
   wt = workingtree.WorkingTree.open('/home/jebw/bzrtest')
 
 
@@ -86,7 +86,7 @@
 
 ``changes_from`` creates a Delta object showing changes::
 
-  from bzrlib import delta
+  from breezy 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
@@ -186,15 +186,15 @@
 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
+  from breezy import log
+  from breezy 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,
+Three log formatters are included with breezy: 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.
@@ -239,7 +239,7 @@
 
 To work with a branch you need a branch object, created from your branch::
 
-  from bzrlib import branch
+  from breezy import branch
 
   b = branch.Branch.open('/home/jebw/bzrtest')
 
@@ -249,17 +249,17 @@
 
 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
+The following code clones the bzr.dev branch (the latest copy of the Breezy
 source code) - be warned it has to download 60meg so takes a while to run
 with no feedback::
 
-  from bzrlib import branch
+  from breezy import branch
 
   b = branch.Branch.open('http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev')
   nb = b.controldir.sprout('/tmp/newBzrBranch').open_branch()
 
 
-This provides no feedback, since Bazaar automatically uses the 'silent' UI.
+This provides no feedback, since Breezy automatically uses the 'silent' UI.
 
 
 Pushing and pulling branches
@@ -268,7 +268,7 @@
 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
+  from breezy import branch
 
   b1 = branch.Branch.open('file:///home/user/mybranch')
   b2 = branch.Branch.open('http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev')
@@ -292,7 +292,7 @@
 
 This performs a Lightweight checkout from an existing Branch::
 
-  from bzrlib import bzrdir
+  from breezy import bzrdir
 
   accelerator_tree, source = bzrdir.BzrDir.open_tree_or_branch('http:URL')
   source.create_checkout('/tmp/newBzrCheckout', None, True, accelerator_tree)

=== modified file 'doc/developers/inventory.txt'
--- doc/developers/inventory.txt	2010-11-12 22:08:18 +0000
+++ doc/developers/inventory.txt	2017-11-11 18:32:23 +0000
@@ -25,7 +25,7 @@
 Serialization
 =============
 
-There are several variants of serialised tree shape in use by bzr. To date
+There are several variants of serialised tree shape in use by Breezy. To date
 these have been mostly XML-based, though plugins have offered non-XML versions.
 
 dirstate
@@ -61,12 +61,12 @@
  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
+ 6. Allow Breezy 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.
+ 7. Let Breezy 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.
+    loggerhead, brz-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.
@@ -127,7 +127,7 @@
 
 Some key layers we have today and can look at using or tweaking are:
 
- * Tree objects - the abstract interface bzrlib code works in
+ * Tree objects - the abstract interface breezy code works in
  * VersionedFiles - the optionally delta compressing key->bytes storage
    interface.
  * Inventory - the abstract interface that many tree operations are written in.
@@ -503,7 +503,7 @@
 =================
 
 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,
+of Breezy'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

=== modified file 'doc/developers/last-modified.txt'
--- doc/developers/last-modified.txt	2009-12-02 20:34:07 +0000
+++ doc/developers/last-modified.txt	2017-11-11 18:32:23 +0000
@@ -90,7 +90,7 @@
 ----------------------------
 
 Accessing a foreign branch requires synthesizing this information.
-If last_modified is removed from a future bzr version, we will also need
+If last_modified is removed from a future Breezy 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

=== modified file 'doc/developers/lca_tree_merging.txt'
--- doc/developers/lca_tree_merging.txt	2008-09-05 02:29:34 +0000
+++ doc/developers/lca_tree_merging.txt	2017-11-11 18:32:23 +0000
@@ -47,7 +47,7 @@
 Resolution Algorithm
 --------------------
 
-(This can be seen as ``bzrlib.merge.Merge3Merger._lca_multi_way```
+(This can be seen as ``breezy.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

=== modified file 'doc/developers/network-protocol.txt'
--- doc/developers/network-protocol.txt	2011-11-29 14:59:18 +0000
+++ doc/developers/network-protocol.txt	2017-11-11 18:32:23 +0000
@@ -70,7 +70,7 @@
           machine until the request can be satisfied,
           sends structured data to the protocol.
 
-Request handlers are registered in the `bzrlib.smart.request` module.
+Request handlers are registered in the `breezy.smart.request` module.
 
 
 Client-side

=== modified file 'doc/developers/overview.txt'
--- doc/developers/overview.txt	2012-02-06 23:39:18 +0000
+++ doc/developers/overview.txt	2017-11-11 18:32:23 +0000
@@ -1,11 +1,11 @@
 =============================
-Bazaar Architectural Overview
+Breezy 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
+This document describes the key classes and concepts within Breezy.  It is
+intended to be useful to people working on the Breezy 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.
+guide to `Integrating with Breezy <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
@@ -15,7 +15,7 @@
 
 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.
+the Breezy mailing list, or simply file a bug report.
 
 
 IDs and keys
@@ -24,7 +24,7 @@
 IDs
 ===
 
-All IDs are globally unique identifiers.  Inside bzrlib they are almost
+All IDs are globally unique identifiers.  Inside breezy they are almost
 always represented as UTF-8 encoded bytestrings (i.e. ``str`` objects).
 
 The main two IDs are:
@@ -33,12 +33,12 @@
   ``[e-mail]-20110201161347-ao76mv267gc1b5v2``
 :File IDs: The unique identifier of a single file.
 
-By convention, in the bzrlib API, parameters of methods that are expected
+By convention, in the breezy 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
+data. Native Breezy 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
@@ -82,7 +82,7 @@
 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
+Inventory file ids are only relevant for native Breezy formats; foreign
 formats don't use inventories.
 
 Transform ids
@@ -160,8 +160,8 @@
 
 See also:
 
-* `Developer guide to bzrlib transports <transports.html>`_ 
-* API docs for ``bzrlib.transport.Transport``
+* `Developer guide to breezy transports <transports.html>`_ 
+* API docs for ``breezy.transport.Transport``
 
 Control directory
 =================
@@ -188,7 +188,7 @@
 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
+The implementation of ``Tree`` for Breezy'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

=== modified file 'doc/developers/packrepo.txt'
--- doc/developers/packrepo.txt	2010-11-12 22:08:18 +0000
+++ doc/developers/packrepo.txt	2017-11-11 18:32:23 +0000
@@ -10,7 +10,7 @@
 Motivation
 ----------
 
-KnitPack is a new repository format for Bazaar, which is expected to be
+KnitPack is a new repository format for Breezy, which is expected to be
 faster both locally and over the network, is usually more compact, and
 will work with more FTP servers.
 
@@ -145,7 +145,7 @@
 ===============
 
 Bazaar 0.92 adds a new format (experimental at first) implemented in
-``bzrlib.repofmt.pack_repo.py``.
+``breezy.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
@@ -186,7 +186,7 @@
                                              compression base
 ======== ========== ======================== ==========================
 
-Indices are accessed through the ``bzrlib.index.GraphIndex`` class.
+Indices are accessed through the ``breezy.index.GraphIndex`` class.
 Indices are stored as sorted files on disk.  Each line is one record,
 and contains:
 

=== added directory 'doc/developers/plans'
=== renamed file 'doc/developers/plans.txt' => 'doc/developers/plans/index.txt'
--- doc/developers/plans.txt	2012-01-24 13:14:06 +0000
+++ doc/developers/plans/index.txt	2017-11-11 18:32:23 +0000
@@ -5,7 +5,5 @@
    :maxdepth: 1
 
    Performance roadmap <performance-roadmap>
-   new-config-rationale
    tortoise-strategy
-   improved_chk_index
    nested-trees

=== renamed file 'doc/developers/nested-trees.txt' => 'doc/developers/plans/nested-trees.txt'
=== added directory 'doc/developers/plans/performance'
=== renamed file 'doc/developers/add.txt' => 'doc/developers/plans/performance/add.txt'
=== renamed file 'doc/developers/annotate.txt' => 'doc/developers/plans/performance/annotate.txt'
=== renamed file 'doc/developers/bundle-creation.txt' => 'doc/developers/plans/performance/bundle-creation.txt'
=== renamed file 'doc/developers/commit.txt' => 'doc/developers/plans/performance/commit.txt'
--- doc/developers/commit.txt	2009-12-02 20:34:07 +0000
+++ doc/developers/plans/performance/commit.txt	2017-11-11 18:32:23 +0000
@@ -101,7 +101,7 @@
 
 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
+will be committed: basically the output of brz 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
@@ -130,7 +130,7 @@
 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
+hash-addressed  file-per-text storage like in git (or Breezy 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
@@ -186,9 +186,9 @@
      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
+   back and forth on. I think the basic idea is that 'brz 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
+   renamed rather than deleted), but 'brz 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
@@ -262,7 +262,7 @@
 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'
+The way I made "brz 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

=== renamed file 'doc/developers/diff.txt' => 'doc/developers/plans/performance/diff.txt'
=== renamed file 'doc/developers/directory-fingerprints.txt' => 'doc/developers/plans/performance/directory-fingerprints.txt'
--- doc/developers/directory-fingerprints.txt	2010-11-12 22:08:18 +0000
+++ doc/developers/plans/performance/directory-fingerprints.txt	2017-11-11 18:32:23 +0000
@@ -223,7 +223,7 @@
 * 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
+  For small trees like bzr, 744 of 874 are in the breezy 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

=== renamed file 'doc/developers/gc.txt' => 'doc/developers/plans/performance/gc.txt'
=== renamed file 'doc/developers/incremental-push-pull.txt' => 'doc/developers/plans/performance/incremental-push-pull.txt'
--- doc/developers/incremental-push-pull.txt	2010-11-12 14:28:36 +0000
+++ doc/developers/plans/performance/incremental-push-pull.txt	2017-11-11 18:32:23 +0000
@@ -14,7 +14,7 @@
 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
+ * Reject corrupt data. As brz has no innate mechanism for discarding corrupted
    data, corrupted data should not be incorporated accidentally.
 
 Factors which should add work for push/pull

=== renamed file 'doc/developers/initial-push-pull.txt' => 'doc/developers/plans/performance/initial-push-pull.txt'
=== renamed file 'doc/developers/merge-scaling.txt' => 'doc/developers/plans/performance/merge-scaling.txt'
=== renamed file 'doc/developers/missing.txt' => 'doc/developers/plans/performance/missing.txt'
=== renamed file 'doc/developers/performance-use-case-analysis.txt' => 'doc/developers/plans/performance/performance-use-case-analysis.txt'
=== renamed file 'doc/developers/planned-change-integration.txt' => 'doc/developers/plans/performance/planned-change-integration.txt'
=== renamed file 'doc/developers/planned-performance-changes.txt' => 'doc/developers/plans/performance/planned-performance-changes.txt'
=== renamed file 'doc/developers/revert.txt' => 'doc/developers/plans/performance/revert.txt'
=== renamed file 'doc/developers/performance-roadmap.txt' => 'doc/developers/plans/performance/roadmap.txt'
--- doc/developers/performance-roadmap.txt	2009-06-10 05:00:47 +0000
+++ doc/developers/plans/performance/roadmap.txt	2017-11-11 18:32:23 +0000
@@ -1,5 +1,5 @@
 ==========================
-Bazaar Performance Roadmap
+Breezy Performance Roadmap
 ==========================
 
 .. Mark sections in included files as following:

=== renamed file 'doc/developers/status.txt' => 'doc/developers/plans/performance/status.txt'
=== renamed file 'doc/developers/uncommit.txt' => 'doc/developers/plans/performance/uncommit.txt'
=== renamed file 'doc/developers/update.txt' => 'doc/developers/plans/performance/update.txt'
=== renamed file 'doc/developers/tortoise-strategy.txt' => 'doc/developers/plans/tortoise-strategy.txt'
=== modified file 'doc/developers/plugin-api.txt'
--- doc/developers/plugin-api.txt	2010-04-16 12:59:03 +0000
+++ doc/developers/plugin-api.txt	2017-11-11 18:32:23 +0000
@@ -11,7 +11,7 @@
 Introduction
 ============
 
-bzrlib has a very flexible internal structure allowing plugins for many
+breezy 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.
@@ -22,15 +22,15 @@
 See also
 --------
 
- * `Bazaar Developer Documentation Catalog <../index.html>`_.
- * `Bazaar Plugins Guide <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_ for
+ * `Breezy Developer Documentation Catalog <../index.html>`_.
+ * `Breezy 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
+Plugins are Python modules under ``breezy.plugins``. They can be installed
 either into the PYTHONPATH in that location, or in ~/.bazaar/plugins.
 
 Plugins should have a setup.py.
@@ -42,12 +42,12 @@
 Plugin metadata before installation
 ===================================
 
-Plugins can export a summary of what they provide, and what versions of bzrlib
+Plugins can export a summary of what they provide, and what versions of breezy
 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
+This interface allows Breezy 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.
@@ -56,7 +56,7 @@
 Metadata protocol
 -----------------
 
-A plugin that supports the bzr plugin metadata protocol will do two
+A plugin that supports the Breezy plugin metadata protocol will do two
 things. Firstly, the ``setup.py`` for the plugin will guard the call to
 ``setup()``::
 
@@ -71,45 +71,45 @@
 +------------------------+---------+----------------------------------------+
 | Variable               | Default | Definition                             |
 +========================+=========+========================================+
-| bzr_plugin_name        | None    | The name the plugin package should be  |
+| brz_plugin_name        | None    | The name the plugin package should be  |
 |                        |         | given on disk. The plugin is then      |
 |                        |         | available to python at                 |
-|                        |         | bzrlib.plugins.NAME                    |
+|                        |         | breezy.plugins.NAME                    |
 +------------------------+---------+----------------------------------------+
-| bzr_commands           | []      | A list of the commands that the plugin |
+| brz_commands           | []      | A list of the commands that the plugin |
 |                        |         | provides. Commands that already exist  |
-|                        |         | in bzr and are decorated by the plugin |
+|                        |         | in brz 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|
+| brz_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    |
+| brz_minimum_version    | None    | A version_info 3-tuple for comparison  |
+|                        |         | with the breezy minimum and current    |
 |                        |         | version, for determining likely        |
 |                        |         | compatibility.                         |
 +------------------------+---------+----------------------------------------+
-| bzr_maximum_version    | None    | A version_info 3-tuple like            |
-|                        |         | bzr_minimum_version but checking the   |
+| brz_maximum_version    | None    | A version_info 3-tuple like            |
+|                        |         | brz_minimum_version but checking the   |
 |                        |         | upper limits supported.                |
 +------------------------+---------+----------------------------------------+
-| bzr_control_formats    | {}      | A dictionary of descriptions of version|
+| brz_control_formats    | {}      | A dictionary of descriptions of version|
 |                        |         | control directories. See               |
 |                        |         | `Control Formats` below.               |
 +------------------------+---------+----------------------------------------+
-| bzr_checkout_formats   | {}      | A dictionary of tree_format_string ->  |
+| brz_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        |
+| brz_branch_formats     | {}      | As brz_checkout_formats but for        |
 |                        |         | branches.                              |
 +------------------------+---------+----------------------------------------+
-| bzr_repository_formats | {}      | As bzr_checkout_formats but for        |
+| brz_repository_formats | {}      | As brz_checkout_formats but for        |
 |                        |         | repositories.                          |
 +------------------------+---------+----------------------------------------+
-| bzr_transports         | []      | URL prefixes for which this plugin     |
+| brz_transports         | []      | URL prefixes for which this plugin     |
 |                        |         | will register transports.              |
 +------------------------+---------+----------------------------------------+
 
@@ -127,10 +127,10 @@
 the content of the file. Thus::
 
   # (look for a .hg directory)
-  bzr_control_formats = {"Mercurial":{'.hg/': None}}
+  brz_control_formats = {"Mercurial":{'.hg/': None}}
 
   # (look for a file called .svn/format with contents 4\n).
-  bzr_control_formats = {"Subversion":{'.svn/format': '4\n'}}
+  brz_control_formats = {"Subversion":{'.svn/format': '4\n'}}
 
 
 Example
@@ -141,21 +141,21 @@
   #!/usr/bin/env python2.4
   from distutils.core import setup
 
-  bzr_plugin_name = 'demo'
-  bzr_commands = [
+  brz_plugin_name = 'demo'
+  brz_commands = [
       'new-command',
       ]
 
-  bzr_branch_formats = {
+  brz_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)
+  brz_control_formats = {"Subversion":{'.svn/format': '4\n'}}
+
+  brz_transports = ["hg+ssh://"]
+
+  brz_plugin_version = (1, 3, 0, 'dev', 0)
+  brz_minimum_version = (1, 0, 0)
 
   if __name__ == 'main':
       setup(name="Demo",
@@ -165,10 +165,10 @@
             author_email="[e-mail]",
             license = "GNU GPL v2",
             url="https://launchpad.net/bzr-demo",
-            packages=['bzrlib.plugins.demo',
-                      'bzrlib.plugins.demo.tests',
+            packages=['breezy.plugins.demo',
+                      'breezy.plugins.demo.tests',
                       ],
-            package_dir={'bzrlib.plugins.demo': '.'})
+            package_dir={'breezy.plugins.demo': '.'})
 
 
 Plugin metadata after installation
@@ -193,14 +193,14 @@
 -----------
 
 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))
+breezy like so::
+
+    from breezy.api import require_api
+
+    require_api(breezy, (1, 11, 0))
 
 Please see `API versioning <api-versioning.html>`_ for more details on the API
-metadata protocol used by bzrlib.
+metadata protocol used by breezy.
 
 Plugin version
 --------------
@@ -219,8 +219,8 @@
 other places.  To detect whether the module is being loaded by bzr, use
 something like this::
 
-    if __name__ == 'bzrlib.plugins.loggerhead':
-        # register with bzrlib...
+    if __name__ == 'breezy.plugins.loggerhead':
+        # register with breezy...
 
 
 Plugin performance
@@ -228,7 +228,7 @@
 
 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
+because this slows down every invocation of bzr.  The breezy APIs
 generally allow the plugin to 'lazily' register methods to invoke if a
 particular disk format or seen or a particular command is run.
 
@@ -240,8 +240,8 @@
 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>`_.
+The plugin can import breezy and call any function.
+Some interesting APIs are described in `Breezy Plugins Guide <http://doc.bazaar.canonical.com/plugins/en/plugin-development.html>`_.
 
 
 Publishing your plugin

=== modified file 'doc/developers/ppa.txt'
--- doc/developers/ppa.txt	2011-02-01 01:34:58 +0000
+++ doc/developers/ppa.txt	2017-11-11 18:32:23 +0000
@@ -1,13 +1,13 @@
-Managing the Bazaar PPA
+Managing the Breezy PPA
 =======================
 
-See also: `Bazaar Developer Document Catalog <index.html>`_.
+See also: `Breezy Developer Document Catalog <index.html>`_.
 
 
 Background
 ----------
 
-We build Ubuntu ``.deb`` packages for Bazaar as an important part of the
+We build Ubuntu ``.deb`` packages for Breezy as an important part of the
 release process.  These packages are hosted in a few `Personal Package
 Archives (PPA)`__ on Launchpad.
 
@@ -48,7 +48,7 @@
 
 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
+so that a complete set of Breezy 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
@@ -121,7 +121,7 @@
 .. _`bzr-builddeb`: http://launchpad.net/bzr-builddeb
 
 
-Packaging Bazaar
+Packaging Breezy
 ----------------
 
 Overview of packaging with builddeb
@@ -227,7 +227,7 @@
 #. 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
+#. For Breezy plugins, change the ``debian/control`` file to express a
    dependency on the correct version of ``bzr``.
 
    For bzrtools this is typically::

=== modified file 'doc/developers/principles.txt'
--- doc/developers/principles.txt	2009-12-14 04:58:08 +0000
+++ doc/developers/principles.txt	2017-11-11 18:32:23 +0000
@@ -1,8 +1,8 @@
 ========================
-Bazaar Design Principles
+Breezy Design Principles
 ========================
 
-We have learned or adopted a few general principles for code in Bazaar.
+We have learned or adopted a few general principles for code in Breezy.
 Generally we will try to follow them in future, either for consistency or
 because they've been proven to work well, or both.  
 
@@ -10,7 +10,7 @@
 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>`_.
+See also: `Breezy Developer Document Catalog <index.html>`_.
 
 
 Testing
@@ -36,7 +36,7 @@
 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
+the format and gives the Breezy release that introduced it.  If the Breezy
 program doesn't understand that format, it can at least show that format
 marker to the user.
 
@@ -49,14 +49,14 @@
 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
+``.bzr/`` are only written to by Breezy and we discourage users from editing
+them.  Within Breezy, code addressing the abstract interface of the Branch,
+ControlDir, 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
+verbatim.  It's OK for Breezy to read and act on these files (as we do
+with ``.bzrignore``), and to update them (as ``brz ignore`` does), but
 they remain clearly user files and can be directly edited.

=== modified file 'doc/developers/profiling.txt'
--- doc/developers/profiling.txt	2009-12-02 20:34:07 +0000
+++ doc/developers/profiling.txt	2017-11-11 18:32:23 +0000
@@ -8,7 +8,7 @@
 information. In the simpliest case, the ``--lsprof`` option can be used as
 shown below::
 
-  bzr --lsprof ...
+  brz --lsprof ...
 
 This will dump the profiling information to stdout before exiting.
 Alternatively, the ``--lsprof-file`` option can be used to specify a filename
@@ -28,10 +28,10 @@
 in combination with KCacheGrind to visualize what the ``status`` command
 is doing::
 
-  bzr --lsprof-file callgrind.out.st001 status
+  brz --lsprof-file callgrind.out.st001 status
   kcachegrind callgrind.out.st001 &
 
-.. Note:: bzr also has a ``--profile`` option that uses the hotshot profiler
+.. Note:: brz 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.
@@ -49,7 +49,7 @@
 identifying unnecessary lock traffic.  This is activated by the ``-Dlock``
 global option.
 
-This writes messages into ``~/.bzr.log``.
+This writes messages into ``~/.brz.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.)

=== added directory 'doc/developers/proposals'
=== modified file 'doc/developers/releasing.txt'
--- doc/developers/releasing.txt	2017-06-06 01:10:48 +0000
+++ doc/developers/releasing.txt	2017-11-11 18:32:23 +0000
@@ -114,9 +114,9 @@
 
 To start a new series cycle:
 
-#. Create a new series ``x.y`` at <https://launchpad.net/bzr/+addseries>.
+#. Create a new series ``x.y`` at <https://launchpad.net/brz/+addseries>.
 
-#. Add milestones at <https://launchpad.net/bzr/x.y/+addmilestone> to that
+#. Add milestones at <https://launchpad.net/brz/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.
@@ -189,8 +189,8 @@
 #. 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
+   <https://launchpad.net/brz/x.y> lists the existing milestones,
+   <https://launchpad.net/brz/x.y/x.y.z/+edit> allows you to toggle the
    active flag.
 
 #. Commit this and send it to PQM.
@@ -205,7 +205,7 @@
 #. 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>.
+   found at <https://launchpad.net/brz/+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
@@ -421,7 +421,7 @@
 Publishing the source tarball
 -----------------------------
 
-#. Go to the relevant <https://launchpad.net/bzr/x.y> series page in Launchpad.
+#. Go to the relevant <https://launchpad.net/brz/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
@@ -497,7 +497,7 @@
      brz push lp:~brz-core/brz/brz-translations-export-x.y
 
 #. On the translations series synchronization settings page
-   <https://translations.launchpad.net/bzr/x.y/+translations-settings>
+   <https://translations.launchpad.net/brz/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.
 
@@ -541,7 +541,7 @@
 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>
+#. Go to the release web page at <https://launchpad.net/brz/x.y/x.y.z>
 
 #. Announce on the Breezy website.
 
@@ -595,15 +595,15 @@
       feedback.
 
       Breezy is now available for download from
-      https://launchpad.net/bzr/x.y/x.y.z/ as a source tarball; packages
+      https://launchpad.net/brz/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>
+#. Make an announcement through <https://launchpad.net/brz/+announce>
+   mentioning the milestone URL <https://launchpad.net/brz/+milestone/x.y.z>
    so people get an easy access to details.
 
 #. Announce on https://freecode.com/projects/bazaar-vcs
@@ -627,8 +627,8 @@
      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/brz-x.ybn.tar.gz>
+     <https://launchpad.net/brz/x.y/x.ybn> and ``Unstable source tarball``
+     <http://launchpad.net/brz/x.y/x.ybn/+download/brz-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.

=== modified file 'doc/developers/repository-stream.txt'
--- doc/developers/repository-stream.txt	2009-12-02 20:34:07 +0000
+++ doc/developers/repository-stream.txt	2017-11-11 18:32:23 +0000
@@ -9,7 +9,7 @@
 
 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
+a single interface for pulling data from and inserting data into a Breezy
 repository.
 
 .. contents::

=== modified file 'doc/developers/repository.txt'
--- doc/developers/repository.txt	2010-11-12 14:28:36 +0000
+++ doc/developers/repository.txt	2017-11-11 18:32:23 +0000
@@ -8,7 +8,7 @@
 :Date: 2007-07-08
 
 This document describes the services repositories offer and need to offer
-within bzrlib.
+within breezy.
 
 
 .. contents::
@@ -24,7 +24,7 @@
 Terminology
 ===========
 
-A **repository** is a store of historical data for bzr.
+A **repository** is a store of historical data for Breezy.
 
 
 Command Requirements
@@ -230,7 +230,7 @@
 ^^^^^^^^^^^^^
 
 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
+every Breezy transaction indexing the new data introduced by the Breezy
 operation. e.g. at the end of fetch. This can be based on the new
 ``GraphIndex`` index type.
 

=== modified file 'doc/developers/revision-properties.txt'
--- doc/developers/revision-properties.txt	2012-02-16 16:42:43 +0000
+++ doc/developers/revision-properties.txt	2017-11-11 18:32:23 +0000
@@ -26,7 +26,7 @@
 ---------------------
 
 At the moment, three standardized revision properties are recognized and used
-by bzrlib:
+by breezy:
 
  * ``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
@@ -40,7 +40,7 @@
    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
+   '<URL> <status>'. Currently, breezy uses only status 'fixed'. See
    `Bug Trackers`_ for more details about using this feature.
 
 .. _Bug Trackers: ../en/user-guide/index.html#bug-trackers

=== modified file 'doc/developers/specifications.txt'
--- doc/developers/specifications.txt	2010-07-07 11:21:19 +0000
+++ doc/developers/specifications.txt	2017-11-11 18:32:23 +0000
@@ -21,13 +21,14 @@
    case-insensitive-file-systems
    development-repo
    packrepo
+   feature-flags
 
 
 * `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.
+* `API versioning <api-versioning.html>`_ |--| breezy API versioning.
 
 * `Apport error reporting <apport.html>`_ |--| Capture data to report
   bugs.
@@ -43,7 +44,7 @@
 * `Groupcompress <groupcompress-design.html>`_ |--| Notes on the compression
   technology used in CHK repositories.
 
-* `Indices <indices.html>`_ |--| The index facilities available within bzrlib.
+* `Indices <indices.html>`_ |--| The index facilities available within breezy.
 
 * `Inventories <inventory.html>`_ |--| Tree shape abstraction.
 
@@ -70,6 +71,10 @@
 * `Knit pack repositories <packrepo.html>`_ |--| KnitPack repositories
   (new in Bazaar 0.92).
 
+* `Format feature flags <feature-flags.html>`_ |--| Allow extending
+  formats with optional features.  (new in Bazaar 2.5).
+
+
 
 .. |--| unicode:: U+2014
 

=== modified file 'doc/developers/transports.txt'
--- doc/developers/transports.txt	2010-11-12 22:08:18 +0000
+++ doc/developers/transports.txt	2017-11-11 18:32:23 +0000
@@ -1,8 +1,8 @@
 ####################################
-Developer guide to bzrlib transports
+Developer guide to breezy transports
 ####################################
 
-This guide describes the `Transport` classes that Bazaar uses for most
+This guide describes the `Transport` classes that Breezy uses for most
 local and remote file access.  (Working tree files are the major
 exception (`bug 606249 <https://bugs.launchpad.net/bzr/+bug/606249>`).
 
@@ -23,17 +23,17 @@
 
     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
+Breezy versions symlinks as objects in their own right, whose content is
+the path they point to.  Breezy 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
+target of a symlink is a byte string; Breezy 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
+So when we say ``brz 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
+However, ``brz 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
@@ -41,7 +41,7 @@
 
 One interesting case for this is ::
 
-    bzr add ~/dev/bug123/a.c
+    brz 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.
@@ -54,7 +54,7 @@
 Useful functions
 ----------------
 
-`bzrlib.osutils.dereference_path` does the commonly useful operation of
+`breezy.osutils.dereference_path` does the commonly useful operation of
 resolving the directory part of a path, but leaving the filename
 untouched.  In other words ::
 
@@ -90,7 +90,7 @@
 
 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
+cannot detect them.  This can cause problems when Breezy 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.
 
@@ -98,9 +98,9 @@
 Symlinks and ChrootTransports
 -----------------------------
 
-bzr has an internal concept of a `ChrootTransport` that locks access into
+Breezy 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.
+which implies they should be expanded and checked within breezy.
 (At least as long as the transport lets us see the symlink; otherwise it
 may not be possible.) 
 

=== modified file 'doc/developers/ui.txt'
--- doc/developers/ui.txt	2010-09-14 06:46:18 +0000
+++ doc/developers/ui.txt	2017-11-11 18:32:23 +0000
@@ -8,7 +8,7 @@
 Processing Command Lines
 ------------------------
 
-bzrlib has a standard framework for parsing command lines and calling
+breezy has a standard framework for parsing command lines and calling
 processing routines associated with various commands. See builtins.py
 for numerous examples.
 
@@ -19,7 +19,7 @@
 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
+should be checked via ``breezy.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.
@@ -28,8 +28,8 @@
 ============
 
 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
+Breezy may want to get confirmation from the user before proceeding.
+However in some circumstances Breezy 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.
@@ -45,13 +45,13 @@
 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``
+``breezy.builtins.uncommit``
     Before the ``uncommit`` command actually changes the branch.
 
-``bzrlib.lockdir.break``
+``breezy.lockdir.break``
     Before breaking a lock.
 
-``bzrlib.msgeditor.unchanged``
+``breezy.msgeditor.unchanged``
     Proceed even though the user made no changes to the template message.
 
 Interactive confirmations can be overridden by using a
@@ -65,7 +65,7 @@
 (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
+breezy 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.
@@ -85,7 +85,7 @@
 
  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
+    be sent through ``breezy.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
@@ -99,7 +99,7 @@
 Progress and Activity Indications
 ---------------------------------
 
-bzrlib has a way for code to display to the user that stuff is happening
+breezy 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
@@ -111,7 +111,7 @@
 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
+top of the stack, call `breezy.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
@@ -157,8 +157,8 @@
 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,
+Breezy has online help for various topics through ``brz help COMMAND`` or
+equivalently ``brz 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
@@ -190,7 +190,7 @@
     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.
+inside breezy.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
@@ -208,7 +208,7 @@
 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
+Many errors are defined in ``breezy/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

=== modified file 'doc/developers/win32_build_setup.txt'
--- doc/developers/win32_build_setup.txt	2010-11-12 22:36:19 +0000
+++ doc/developers/win32_build_setup.txt	2017-11-11 18:32:23 +0000
@@ -22,7 +22,7 @@
 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
+   install cygwin's python or Breezy package. As we are only interested in
    running the native version of bzr. For information on running the cygwin
    port of bzr, look elsewhere.
 

=== removed file 'doc/developers/xdg_config_spec.txt'
--- doc/developers/xdg_config_spec.txt	2014-02-14 10:29:49 +0000
+++ doc/developers/xdg_config_spec.txt	1970-01-01 00:00:00 +0000
@@ -1,24 +0,0 @@
-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.
-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 which should use their own native configuration
-locations.  (On Windows, we currently do this by working under %APPDATA%.
-
-* 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.

=== modified file 'doc/en/release-notes/brz-3.0.txt'
--- doc/en/release-notes/brz-3.0.txt	2017-10-07 13:27:26 +0000
+++ doc/en/release-notes/brz-3.0.txt	2017-11-11 18:32:23 +0000
@@ -140,6 +140,9 @@
   Thanks to Augie Fackler for reporting.
   (Jelmer Vernooij, #1710979)
 
+* Support automatic rename tracking into new directories.
+  (mnn, #373319)
+
 Documentation
 *************