Rev 4661: Merge integration. in http://bazaar.launchpad.net/~lifeless/bzr/bug-416732
Robert Collins
robertc at robertcollins.net
Sun Aug 30 22:45:00 BST 2009
At http://bazaar.launchpad.net/~lifeless/bzr/bug-416732
------------------------------------------------------------
revno: 4661 [merge]
revision-id: robertc at robertcollins.net-20090830214442-r7vbzzj0etp81929
parent: robertc at robertcollins.net-20090830194952-2wynnw5mgb6wnrtx
parent: robertc at robertcollins.net-20090830213442-5wkf4ii9pno1ft5e
committer: Robert Collins <robertc at robertcollins.net>
branch nick: bug-416732
timestamp: Mon 2009-08-31 07:44:42 +1000
message:
Merge integration.
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-30 02:47:30 +0000
+++ b/NEWS 2009-08-30 21:44:42 +0000
@@ -61,8 +61,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