Rev 4664: (robertc) Merge 2.0 to bzr.dev, in file:///home/pqm/archives/thelove/bzr/%2Btrunk/

Canonical.com Patch Queue Manager pqm at pqm.ubuntu.com
Sun Aug 30 23:15:32 BST 2009


At file:///home/pqm/archives/thelove/bzr/%2Btrunk/

------------------------------------------------------------
revno: 4664 [merge]
revision-id: pqm at pqm.ubuntu.com-20090830221530-cyl2ubhnn49s05m2
parent: pqm at pqm.ubuntu.com-20090828222440-jt2m0uvoy126e5kz
parent: robertc at robertcollins.net-20090830213442-5wkf4ii9pno1ft5e
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Sun 2009-08-30 23:15:30 +0100
message:
  (robertc) Merge 2.0 to bzr.dev,
  	including fixes for log and serialisation of
  	IncompatibleRepositories. (Robert Collins, John Arbash Meinel)
modified:
  NEWS                           NEWS-20050323055033-4e00b5db738777ff
  bzrlib/__init__.py             __init__.py-20050309040759-33e65acf91bbcd5d
  bzrlib/groupcompress.py        groupcompress.py-20080705181503-ccbxd6xuy1bdnrpu-8
  bzrlib/knit.py                 knit.py-20051212171256-f056ac8f0fbe1bd9
  bzrlib/tests/per_versionedfile.py test_versionedfile.py-20060222045249-db45c9ed14a1c2e5
  doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
=== modified file 'NEWS'
--- a/NEWS	2009-08-28 22:24:40 +0000
+++ b/NEWS	2009-08-30 21:34:42 +0000
@@ -57,8 +57,12 @@
 Bug Fixes
 *********
 
-* Fix a potential segmentation fault when doing 'log' of a branch that had
-  ghosts in its mainline. (evaluating None as a tuple is bad.)
+* ``bzr log stacked-branch`` shows the full log including
+  revisions that are in the fallback repository. (Regressed in 2.0rc1).
+  (John Arbash Meinel, #419241)
+
+* Fix a segmentation fault when computing the ``merge_sort`` of a graph
+  that has a ghost in the mainline ancestry.
   (John Arbash Meinel, #419241)
 
 

=== modified file 'bzrlib/__init__.py'
--- a/bzrlib/__init__.py	2009-08-28 04:13:16 +0000
+++ b/bzrlib/__init__.py	2009-08-30 21:34:42 +0000
@@ -70,6 +70,8 @@
     1.2dev
     >>> print _format_version_tuple((1, 1, 1, 'candidate', 2))
     1.1.1rc2
+    >>> print bzrlib._format_version_tuple((2, 1, 0, 'beta', 1))
+    2.1b1
     >>> print _format_version_tuple((1, 4, 0))
     1.4
     >>> print _format_version_tuple((1, 4))

=== modified file 'bzrlib/groupcompress.py'
--- a/bzrlib/groupcompress.py	2009-08-28 05:00:33 +0000
+++ b/bzrlib/groupcompress.py	2009-08-30 21:34:42 +0000
@@ -1210,8 +1210,17 @@
 
     def get_known_graph_ancestry(self, keys):
         """Get a KnownGraph instance with the ancestry of keys."""
-        parent_map, missing_keys = self._index._graph_index.find_ancestry(keys,
-                                                                          0)
+        # Note that this is identical to
+        # KnitVersionedFiles.get_known_graph_ancestry, but they don't share
+        # ancestry.
+        parent_map, missing_keys = self._index.find_ancestry(keys)
+        for fallback in self._fallback_vfs:
+            if not missing_keys:
+                break
+            (f_parent_map, f_missing_keys) = fallback._index.find_ancestry(
+                                                missing_keys)
+            parent_map.update(f_parent_map)
+            missing_keys = f_missing_keys
         kg = _mod_graph.KnownGraph(parent_map)
         return kg
 
@@ -1831,6 +1840,10 @@
             if missing_keys:
                 raise errors.RevisionNotPresent(missing_keys.pop(), self)
 
+    def find_ancestry(self, keys):
+        """See CombinedGraphIndex.find_ancestry"""
+        return self._graph_index.find_ancestry(keys, 0)
+
     def get_parent_map(self, keys):
         """Get a map of the parents of keys.
 

=== modified file 'bzrlib/knit.py'
--- a/bzrlib/knit.py	2009-08-28 04:13:16 +0000
+++ b/bzrlib/knit.py	2009-08-30 21:34:42 +0000
@@ -1193,6 +1193,13 @@
     def get_known_graph_ancestry(self, keys):
         """Get a KnownGraph instance with the ancestry of keys."""
         parent_map, missing_keys = self._index.find_ancestry(keys)
+        for fallback in self._fallback_vfs:
+            if not missing_keys:
+                break
+            (f_parent_map, f_missing_keys) = fallback._index.find_ancestry(
+                                                missing_keys)
+            parent_map.update(f_parent_map)
+            missing_keys = f_missing_keys
         kg = _mod_graph.KnownGraph(parent_map)
         return kg
 

=== modified file 'bzrlib/tests/per_versionedfile.py'
--- a/bzrlib/tests/per_versionedfile.py	2009-08-17 22:08:21 +0000
+++ b/bzrlib/tests/per_versionedfile.py	2009-08-26 16:44:27 +0000
@@ -1757,6 +1757,29 @@
         self.assertIsInstance(kg, _mod_graph.KnownGraph)
         self.assertEqual([key_a, key_b, key_c], list(kg.topo_sort()))
 
+    def test_known_graph_with_fallbacks(self):
+        f = self.get_versionedfiles('files')
+        if not self.graph:
+            raise TestNotApplicable('ancestry info only relevant with graph.')
+        if getattr(f, 'add_fallback_versioned_files', None) is None:
+            raise TestNotApplicable("%s doesn't support fallbacks"
+                                    % (f.__class__.__name__,))
+        key_a = self.get_simple_key('a')
+        key_b = self.get_simple_key('b')
+        key_c = self.get_simple_key('c')
+        # A     only in fallback
+        # |\
+        # | B
+        # |/
+        # C
+        g = self.get_versionedfiles('fallback')
+        g.add_lines(key_a, [], ['\n'])
+        f.add_fallback_versioned_files(g)
+        f.add_lines(key_b, [key_a], ['\n'])
+        f.add_lines(key_c, [key_a, key_b], ['\n'])
+        kg = f.get_known_graph_ancestry([key_c])
+        self.assertEqual([key_a, key_b, key_c], list(kg.topo_sort()))
+
     def test_get_record_stream_empty(self):
         """An empty stream can be requested without error."""
         f = self.get_versionedfiles()

=== modified file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt	2009-08-28 05:00:33 +0000
+++ b/doc/developers/releasing.txt	2009-08-30 21:34:42 +0000
@@ -17,21 +17,51 @@
 
      bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
 
-Starting the release phase
---------------------------
-
-When it's time to make the release candidate:
+
+Starting a cycle
+----------------
+
+To start a new release cycle:
+
+#. Create a new series at <https://launchpad.net/bzr/+addseries>. There is one
+   series for every *x.y* release.
+
+#. Go to the series web page at <https://launchpad.net/bzr/2.0>
+
+#. Create a new release at
+   <https://launchpad.net/bzr/2.0/+addrelease> and add
+   information about this release. We will not use it yet, but it
+   will be available for targeting or nominating bugs.
 
 #. We create a new pqm-controlled branch for this release series, by
    asking a Canonical sysadmin.  
-   This branch means that from the first release candidate onwards,
+   This branch means that from the first release beta or candidate onwards,
    general development continues on the trunk, and only
-   specifically-targetted fixes go into the release.
-
-#. Register the branch at <https://launchpad.net/products/bzr/+addbranch>
-
-#. Make a release candidate.
-
+   specifically-targeted fixes go into the release branch.
+
+#. Add milestones at <https://edge.launchpad.net/bzr/2.0/+addmilestone> to
+   that series for the beta release, release candidate and the final release,
+   and their expected dates.
+
+#. Update the version number in the ``bzr`` script, and the
+   ``bzrlib/__init__.py`` file.
+
+#. Send mail to the list with the key dates, who will be the release
+   manager, and the main themes or targeted bugs.  Ask people to nominate
+   objectives, or point out any high-risk things that are best done early,
+   or that interact with other changes. This is called the metronome mail
+   and as RM you're supposed to send other metronome mails at your rythm.
+
+
+Starting the release phase
+--------------------------
+
+When it's time to make the first beta release or release candidate:
+
+#. Create a new milestone at <https://launchpad.net/bzr/2.0/+addmilestone>
+   for the beta release or release candidate.
+
+#. Make a beta release or release candidate.
 
 Preparing the tree for release
 ------------------------------
@@ -46,17 +76,27 @@
 
 	[/home/mbp/bzr/prepare-1.14]
 	pqm_email = Canonical PQM <pqm at bazaar-vcs.org>
-	submit_branch = http://bazaar-vcs.org/bzr/bzr.1.14
-	public_branch = http://bazaar.your-domain.com/bzr
+	submit_branch = lp:bzr/2.0
+	public_branch = http://bazaar.example.com/prepare-2.0
 	submit_to = bazaar at lists.canonical.com
-	smtp_server = mail.your-domain.com:25
+	smtp_server = mail.example.com:25
 
     Please see <http://doc.bazaar-vcs.org/latest/developers/HACKING.html#an-overview-of-pqm>
     for more details on PQM
 
 #. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``.
    Double check that ./bzr ``_script_version`` matches ``version_info``. Check
-   the output of ``bzr --version``. 
+   the output of ``bzr --version``.
+
+   For beta releases use::
+
+       version_info = (2, 1, 0, 'beta', 1)
+
+
+   For release candidates use::
+
+       version_info = (2, 0, 1, 'candidate', 1)
+
 
 #. Add the date and release number to ``./NEWS``
 
@@ -141,16 +181,20 @@
  
      make check-dist-tarball
 
+   You may encounter failures while running the test suite caused
+   by your locally installed plugins. Use your own judgment to
+   decide if you can release with these failures. When in doubt,
+   disable the faulty plugins one by one until you get no more
+   failures.
+
 
 Publishing the release
 ----------------------
 
-Now you have the releasable product.  The next step is making it
+Now you have the beta or releasable product.  The next step is making it
 available to the world.
 
-#. In <https://launchpad.net/bzr/> click the "Release series" for this
-   series, to take you to e.g. <https://launchpad.net/bzr/1.14>.  Then
-   click "Register a release", and add information about this release.
+go to the release
 
 #. Within that release, upload the source tarball and zipfile and the GPG
    signature.  Or, if you prefer, use the
@@ -160,10 +204,11 @@
 
 #. Announce on the `Bazaar home page <http://bazaar-vcs.org/>`_.
 
-#. Check that the documentation for this release is available in 
-   <http://doc.bazaar-vcs.org>.  It should be automatically build when the 
+#. Check that the documentation for this release is available in
+   <http://doc.bazaar-vcs.org>.  It should be automatically build when the
    branch is created, by a cron script ``update-bzr-docs`` on
-   ``escudero``.
+   ``escudero``. As of today (2009-08-27) ``igc`` manually updates the
+   pretty version of it.
 
 
 Announcing the release
@@ -173,12 +218,17 @@
 
 #. Make an announcement mail.
 
-   For release candidates, this is sent to the ``bazaar-announce`` and
-   ``bazaar`` lists.  For final releases, it should also be cc'd to 
-   ``info-gnu at gnu.org``, ``python-announce-list at python.org``, 
-   ``bug-directory at gnu.org``.  In both cases, it is good to set
-   ``Reply-To: bazaar at lists.canonical.com``, so that people who reply to
-   the announcement don't spam other lists.
+   For release candidates or beta releases, this is sent to the ``bazaar``
+   list only to inform plugin authors and package or installer managers.
+
+   Once the installers are available, the mail can be sent to the
+   ``bazaar-announce`` list too.
+
+   For final releases, it should also be cc'd to ``info-gnu at gnu.org``,
+   ``python-announce-list at python.org``, ``bug-directory at gnu.org``.  
+
+   In all cases, it is good to set ``Reply-To: bazaar at lists.canonical.com``,
+   so that people who reply to the announcement don't spam other lists.
 
    The announce mail will look something like this::
    
@@ -208,12 +258,12 @@
 
 #. Announce on http://freshmeat.net/projects/bzr/
    
-   This should be done for both release candidates and final releases. If
-   you do not have a Freshmeat account yet, ask one of the existing
-   admins.
+   This should be done for beta releases, release candidates and final
+   releases. If you do not have a Freshmeat account yet, ask one of the
+   existing admins.
 
-#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should be done
-for final releases but not for Release Candidates.
+#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
+   be done for final releases but not for beta releases or Release Candidates.
 
 #. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
    done by running ::
@@ -240,28 +290,6 @@
 at any time.
 
 
-Starting a cycle
-----------------
-
-To start a new release cycle:
-
-#. Send mail to the list with the key dates, who will be the release
-   manager, and the main themes or targeted bugs.  Ask people to nominate
-   objectives, or point out any high-risk things that are best done early,
-   or that interact with other changes.
-
-#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>.  
-   There is one series for every *x.y* release.
-
-#. Add milestones to that series for the release candidate and the final
-   release, and their expected dates.
-
-#. Deactivate old releases and their milestones.
-
-#. Update the version number in the ``bzr`` script, and the
-   ``bzrlib/__init__.py`` file.
-
-
 See also
 --------
 




More information about the bazaar-commits mailing list