Stacking is not fully transitive
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Bazaar |
Critical
|
Martin Pool | ||
| 2.2 |
Critical
|
Martin Pool | ||
| 2.3 |
Critical
|
Martin Pool | ||
| Launchpad itself |
Critical
|
William Grant | ||
| Ubuntu Distributed Development |
High
|
canonical-bazaar | ||
| bzr (Ubuntu) |
Undecided
|
Unassigned | ||
| Maverick |
Undecided
|
Unassigned | ||
| Natty |
High
|
Jelmer Vernooij |
Bug Description
Stacking is not transitive in all cases. For example, bzr log -n0 will fail if a revision is only present two levels down.
- bzr init foo
- cd foo
- bzr ci --unchanged -m "foo"
- bzr push --stacked-on=. ../bar
- bzr push --stacked-on=../bar ../baz
- bzr log -n0 ../baz
BOOM like http://
Related branches
- bzr-core: Pending requested 2011-02-09
-
Diff: 132 lines (+66/-3)6 files modifiedNEWS (+4/-0)
bzrlib/groupcompress.py (+2/-2)
bzrlib/knit.py (+1/-1)
bzrlib/tests/per_repository_reference/__init__.py (+1/-0)
bzrlib/tests/per_repository_reference/test_graph.py (+45/-0)
bzrlib/versionedfile.py (+13/-0)
- Robert Collins (community): Approve on 2011-02-08
-
Diff: 243 lines (+146/-3) (has conflicts)8 files modifiedbzr (+4/-0)
bzrlib/__init__.py (+4/-0)
bzrlib/groupcompress.py (+2/-2)
bzrlib/knit.py (+1/-1)
bzrlib/tests/per_repository_reference/__init__.py (+1/-0)
bzrlib/tests/per_repository_reference/test_graph.py (+45/-0)
bzrlib/versionedfile.py (+13/-0)
doc/en/release-notes/bzr-2.3.txt (+76/-0)
- Robert Collins (community): Approve on 2011-02-09
-
Diff: 12 lines (+1/-1)1 file modifiedversions.cfg (+1/-1)
- Colin Watson: Approve on 2012-01-27
- Ubuntu Sponsors Team: Pending requested 2012-01-23
-
Diff: 1694 lines (+1330/-32)24 files modifiedMakefile (+1/-1)
NEWS (+107/-1)
bzr (+2/-2)
bzrlib/__init__.py (+3/-3)
bzrlib/groupcompress.py (+2/-2)
bzrlib/help_topics/en/configuration.txt (+3/-1)
bzrlib/knit.py (+1/-1)
bzrlib/merge.py (+8/-2)
bzrlib/plugins/launchpad/__init__.py (+64/-4)
bzrlib/plugins/launchpad/lp_api_lite.py (+285/-0)
bzrlib/plugins/launchpad/test_lp_api_lite.py (+557/-0)
bzrlib/repofmt/groupcompress_repo.py (+13/-4)
bzrlib/tests/per_repository_reference/__init__.py (+1/-0)
bzrlib/tests/per_repository_reference/test_graph.py (+45/-0)
bzrlib/tests/test_config.py (+27/-1)
bzrlib/tests/test_conflicts.py (+64/-0)
bzrlib/tests/test_repository.py (+101/-1)
bzrlib/transport/http/_pycurl.py (+5/-5)
bzrlib/util/configobj/configobj.py (+4/-2)
bzrlib/versionedfile.py (+13/-0)
debian/changelog (+10/-0)
debian/watch (+1/-1)
doc/en/whats-new/whats-new-in-2.2.txt (+4/-1)
setup.py (+9/-0)
- Ubuntu Stable Release Updates Team: Pending requested 2011-09-27
-
Diff: 22226 lines (+6010/-3281)170 files modified.pc/applied-patches (+1/-1)
.pc/debian-changes-2.2.0-1/bzrlib/rules.py (+0/-155)
.pc/debian-changes-2.2.0-1/bzrlib/xml_serializer.py (+0/-195)
.pc/debian-changes-2.2.1-0ubuntu1/bzrlib/rules.py (+155/-0)
.pc/debian-changes-2.2.1-0ubuntu1/bzrlib/xml_serializer.py (+197/-0)
Makefile (+1/-1)
NEWS (+724/-232)
bzr (+12/-13)
bzrlib/__init__.py (+3/-3)
bzrlib/_annotator_pyx.c (+108/-108)
bzrlib/_bencode_pyx.c (+128/-128)
bzrlib/_btree_serializer_pyx.c (+150/-150)
bzrlib/_chk_map_pyx.c (+212/-212)
bzrlib/_chunks_to_lines_pyx.c (+36/-36)
bzrlib/_dirstate_helpers_pyx.c (+602/-602)
bzrlib/_groupcompress_pyx.c (+186/-186)
bzrlib/_knit_load_data_pyx.c (+90/-90)
bzrlib/_known_graph_pyx.c (+349/-349)
bzrlib/_patiencediff_c.c (+2/-2)
bzrlib/_readdir_pyx.c (+76/-76)
bzrlib/_rio_pyx.c (+77/-77)
bzrlib/_simple_set_pyx.c (+146/-146)
bzrlib/branch.py (+2/-7)
bzrlib/commands.py (+1/-0)
bzrlib/commit.py (+12/-1)
bzrlib/conflicts.py (+6/-7)
bzrlib/dirstate.py (+11/-5)
bzrlib/doc_generate/autodoc_man.py (+2/-2)
bzrlib/errors.py (+24/-0)
bzrlib/fetch.py (+5/-4)
bzrlib/generate_ids.py (+4/-4)
bzrlib/groupcompress.py (+2/-2)
bzrlib/help_topics/__init__.py (+1/-1)
bzrlib/help_topics/en/configuration.txt (+3/-1)
bzrlib/inventory.py (+0/-3)
bzrlib/knit.py (+1/-1)
bzrlib/lockdir.py (+44/-2)
bzrlib/merge.py (+8/-2)
bzrlib/mutabletree.py (+18/-0)
bzrlib/plugins/launchpad/__init__.py (+64/-4)
bzrlib/plugins/launchpad/lp_api.py (+19/-6)
bzrlib/plugins/launchpad/lp_api_lite.py (+285/-0)
bzrlib/plugins/launchpad/lp_propose.py (+1/-1)
bzrlib/plugins/launchpad/lp_registration.py (+2/-2)
bzrlib/plugins/launchpad/test_lp_api_lite.py (+557/-0)
bzrlib/plugins/launchpad/test_lp_service.py (+0/-12)
bzrlib/plugins/launchpad/test_register.py (+2/-2)
bzrlib/repofmt/groupcompress_repo.py (+13/-4)
bzrlib/repofmt/pack_repo.py (+38/-4)
bzrlib/repository.py (+1/-2)
bzrlib/revisiontree.py (+1/-1)
bzrlib/tests/__init__.py (+13/-1)
bzrlib/tests/blackbox/test_add.py (+9/-0)
bzrlib/tests/blackbox/test_alias.py (+4/-2)
bzrlib/tests/blackbox/test_commit.py (+2/-0)
bzrlib/tests/blackbox/test_conflicts.py (+45/-0)
bzrlib/tests/blackbox/test_export.py (+5/-8)
bzrlib/tests/blackbox/test_tags.py (+56/-9)
bzrlib/tests/features.py (+15/-0)
bzrlib/tests/per_interrepository/__init__.py (+14/-3)
bzrlib/tests/per_lock/test_lock.py (+2/-1)
bzrlib/tests/per_repository/test_commit_builder.py (+24/-0)
bzrlib/tests/per_repository_reference/__init__.py (+1/-0)
bzrlib/tests/per_repository_reference/test_graph.py (+45/-0)
bzrlib/tests/per_tree/__init__.py (+1/-0)
bzrlib/tests/per_tree/test_is_executable.py (+37/-0)
bzrlib/tests/per_workingtree/test_symlinks.py (+79/-2)
bzrlib/tests/test_branch.py (+9/-0)
bzrlib/tests/test_bzrdir.py (+10/-0)
bzrlib/tests/test_commands.py (+1/-0)
bzrlib/tests/test_config.py (+27/-1)
bzrlib/tests/test_conflicts.py (+153/-1)
bzrlib/tests/test_dirstate.py (+16/-0)
bzrlib/tests/test_errors.py (+16/-0)
bzrlib/tests/test_http.py (+2/-0)
bzrlib/tests/test_knit.py (+27/-0)
bzrlib/tests/test_lockdir.py (+103/-1)
bzrlib/tests/test_osutils.py (+10/-3)
bzrlib/tests/test_repository.py (+101/-1)
bzrlib/tests/test_rio.py (+8/-0)
bzrlib/tests/test_selftest.py (+42/-6)
bzrlib/tests/test_setup.py (+5/-5)
bzrlib/tests/test_transform.py (+5/-3)
bzrlib/tests/test_workingtree.py (+7/-7)
bzrlib/transform.py (+8/-3)
bzrlib/transport/ftp/__init__.py (+11/-1)
bzrlib/transport/http/_pycurl.py (+8/-6)
bzrlib/transport/http/_urllib.py (+4/-2)
bzrlib/transport/http/_urllib2_wrappers.py (+13/-9)
bzrlib/transport/ssh.py (+25/-8)
bzrlib/util/configobj/configobj.py (+4/-2)
bzrlib/versionedfile.py (+13/-0)
bzrlib/workingtree.py (+7/-2)
bzrlib/workingtree_4.py (+1/-1)
bzrlib/xml_serializer.py (+2/-0)
debian/changelog (+49/-0)
debian/patches/debian-changes-2.2.0-1 (+0/-86)
debian/patches/debian-changes-2.2.1-0ubuntu1 (+60/-0)
debian/patches/series (+1/-1)
debian/watch (+2/-2)
doc/developers/HACKING.txt (+4/-4)
doc/developers/bug-handling.txt (+13/-11)
doc/developers/case-insensitive-file-systems.txt (+1/-1)
doc/developers/content-filtering.txt (+3/-3)
doc/developers/contribution-quickstart.txt (+1/-1)
doc/developers/development-repo.txt (+1/-1)
doc/developers/ec2.txt (+3/-3)
doc/developers/index-plain.txt (+2/-2)
doc/developers/packrepo.txt (+1/-1)
doc/developers/planned-performance-changes.txt (+0/-7)
doc/developers/releasing.txt (+19/-15)
doc/en/_templates/index.html (+1/-1)
doc/en/admin-guide/code-browsing.txt (+2/-2)
doc/en/admin-guide/hooks-plugins.txt (+4/-4)
doc/en/admin-guide/migration.txt (+2/-2)
doc/en/admin-guide/simple-setups.txt (+1/-1)
doc/en/admin-guide/upgrade.txt (+2/-2)
doc/en/mini-tutorial/index.txt (+6/-6)
doc/en/tutorials/centralized_workflow.txt (+3/-3)
doc/en/tutorials/tutorial.txt (+3/-3)
doc/en/tutorials/using_bazaar_with_launchpad.txt (+1/-1)
doc/en/upgrade-guide/overview.txt (+1/-1)
doc/en/user-guide/branching_a_project.txt (+1/-1)
doc/en/user-guide/bzrtools_plugin.txt (+1/-1)
doc/en/user-guide/configuring_bazaar.txt (+2/-2)
doc/en/user-guide/hooks.txt (+1/-1)
doc/en/user-guide/installing_bazaar.txt (+4/-4)
doc/en/user-guide/introducing_bazaar.txt (+3/-3)
doc/en/user-guide/plugins.txt (+3/-3)
doc/en/user-guide/sending_changes.txt (+1/-1)
doc/en/user-guide/server.txt (+1/-1)
doc/en/user-guide/setting_up_email.txt (+1/-1)
doc/en/user-guide/shared_repository_layouts.txt (+1/-1)
doc/en/user-guide/specifying_revisions.txt (+1/-1)
doc/en/user-guide/svn_plugin.txt (+2/-2)
doc/en/user-guide/version_info.txt (+1/-1)
doc/en/user-guide/web_browsing.txt (+1/-1)
doc/en/user-guide/writing_a_plugin.txt (+2/-2)
doc/en/user-reference/readme.txt (+1/-1)
doc/en/whats-new/whats-new-in-2.1.txt (+10/-0)
doc/en/whats-new/whats-new-in-2.2.txt (+288/-44)
doc/es/index.txt (+6/-6)
doc/es/mini-tutorial/index.txt (+6/-6)
doc/index.es.txt (+7/-7)
doc/index.ja.txt (+5/-5)
doc/index.ru.txt (+5/-5)
doc/index.txt (+5/-5)
doc/ja/index.txt (+6/-6)
doc/ja/mini-tutorial/index.txt (+6/-6)
doc/ja/tutorials/centralized_workflow.txt (+3/-3)
doc/ja/tutorials/tutorial.txt (+3/-3)
doc/ja/tutorials/using_bazaar_with_launchpad.txt (+1/-1)
doc/ja/upgrade-guide/overview.txt (+1/-1)
doc/ja/user-guide/bzrtools_plugin.txt (+1/-1)
doc/ja/user-guide/installing_bazaar.txt (+5/-5)
doc/ja/user-guide/introducing_bazaar.txt (+3/-3)
doc/ja/user-guide/plugins.txt (+1/-1)
doc/ja/user-guide/server.txt (+1/-1)
doc/ja/user-guide/shared_repository_layouts.txt (+1/-1)
doc/ja/user-guide/svn_plugin.txt (+2/-2)
doc/ja/user-guide/web_browsing.txt (+1/-1)
doc/ja/user-reference/index.txt (+19/-22)
doc/ru/index.txt (+3/-3)
doc/ru/mini-tutorial/index.txt (+6/-6)
doc/ru/tutorials/centralized_workflow.txt (+3/-3)
doc/ru/tutorials/tutorial.txt (+3/-3)
doc/ru/tutorials/using_bazaar_with_launchpad.txt (+1/-1)
doc/ru/user-guide/introducing_bazaar.txt (+3/-3)
setup.py (+18/-5)
tools/check-newsbugs.py (+2/-1)
James Westby (james-w) wrote : | #1 |
James Westby (james-w) wrote : | #2 |
Trying with lp:ubuntu/lucid/ssss I see
471 known_graph = self.repository
472 [last_revision])
which internally fails to find last_revision in either of the _fallback_vfs that it checks.
I suspect this bug occurs when the tip revision is in a stacked-on repository. It may
happen when any revision in the history is stored in a stacked-on repo, I'm not
sure yet.
Thanks,
James
Changed in bzr: | |
status: | New → Confirmed |
assignee: | nobody → canonical-bazaar (canonical-bazaar) |
importance: | Undecided → High |
James Westby (james-w) wrote : | #3 |
Hi,
There is a chain of stacking
A -> B -> C
(-> means stacked on).
We open A, which gets B as a fallback, which causes B to be opened which gets
C as a fallback.
We then try to get the known_graph of A, and we reach this code (groupcompress.py)
def get_known_
"""Get a KnownGraph instance with the ancestry of keys."""
# Note that this is identical to
# KnitVersionedFi
# ancestry.
parent_map, missing_keys = self._index.
for fallback in self._fallback_vfs:
if not missing_keys:
So we are inside A.revisions, and we don't find the revision in our index, so we
look in the fallback, B.revisions, which doesn't have it either. If we looked in A.revisions
we would find it, but we don't.
Rob says:
<james_w> I would have assumed that most of this code didn't recurse at all call-sites, and just collected all the fallbacks when opening in to _fallback_vfs
<lifeless> each repo is mutable
<lifeless> so open is the wrong time
<lifeless> flattening at execution is probably appropriate
<lifeless> that or recursing via the public api
I am not going to work on this any further, so someone else should take it over
to stop Launchpad from OOPSing.
Thanks,
James
Andrew Bennetts (spiv) wrote : | #4 |
This is causing Launchpad to OOPS when scanning branches generated by the package importer. It seems likely the package importer and/or users of those branches may encounter similar issues too. wgrant suggests the backlog of unscannable branches may become a problem for Launchpad too.
So I'm tentatively bumping this up to Critical.
Changed in bzr: | |
importance: | High → Critical |
tags: | added: stacking udd |
Changed in bzr: | |
assignee: | canonical-bazaar (canonical-bazaar) → Martin Pool (mbp) |
status: | Confirmed → In Progress |
Martin Pool (mbp) wrote : | #5 |
Thanks for localizing it, James.
I think bug 571962 is similar, or maybe a dupe.
I have a passing test.
I think I understand #3 which is that although that function looks like it's iterating across all the fallbacks, it doesn't actually have them all in the list yet. That's a bit of a trap and there may well be other occurrences.
Martin Pool (mbp) wrote : | #6 |
It looks like get_parent_map and _get_parent_
Doing so seems to fix my test for it, assuming it's representative.
If we're comfortable with this fix, we should also grep for _fallback_vfs and update them, and perhaps even rename that to something like _immediate_
John A Meinel (jameinel) wrote : | #7 |
Just to mention fetch already has code for tracking through fallbacks, as it was the first place we encountered it.
What we have to watch out for is whether operations can happen remotely or not. Imagine this case:
A stacked on B stacked on C
A = local branch and repository
B = Launchpad branch B
C = Launchpad branch C
The issue is that the local client has something like:
RepoA is a GroupCompressRepo with _fallback_
RemoteRepoB is a RemoteRepository with _fallback_
RemoteRepoC is a RemoteRepository with _fallback_
However, on the server side, we have:
RepoB is a GroupCompressRepo with _fallback_
RepoC is a GroupCompressRepo with _fallback_
Fetch is currently special, because it is evaluated in the server side. So client-side fetch had to be updated, since server side repositories don't see their fallbacks.
Note that VersionedFile objects get an equivalent VF for fallbacks.
I'm also pretty sure that at least James didn't realize that
RepoA._
On 9 February 2011 08:32, John A Meinel <email address hidden> wrote:
> I'm also pretty sure that at least James didn't realize that
> RepoA._
I did not realize that either. I think it's kind of a dangerous
interface that way.
Robert Collins (lifeless) wrote : | #9 |
On Wed, Feb 9, 2011 at 11:23 AM, Martin Pool <email address hidden> wrote:
> On 9 February 2011 08:32, John A Meinel <email address hidden> wrote:
>> I'm also pretty sure that at least James didn't realize that
>> RepoA._
>
> I did not realize that either. I think it's kind of a dangerous
> interface that way.
Its the immediate fallbacks; they can have their own - and a repo can
have N immediate fallbacks because of shared repositories with stacked
branches in the repo.
Flattening it is possible, but you want to make sure you still have
the fallback repositories know their own fallbacks so they can
maintain their own invariants about inventories, revisions etc. The
downside if you flatten it then is that you need two apis - a
non-recursive one and a recursive one, or you'll end up handling
fallbacks twice - once in the top level, and then once in the first
level. Of course this can still happen when you have several direct
fallbacks, but thats very uncommon today.
-Rob
Martin Pool (mbp) wrote : | #10 |
On 9 February 2011 10:00, Robert Collins <email address hidden> wrote:
> On Wed, Feb 9, 2011 at 11:23 AM, Martin Pool <email address hidden> wrote:
>> On 9 February 2011 08:32, John A Meinel <email address hidden> wrote:
>>> I'm also pretty sure that at least James didn't realize that
>>> RepoA._
>>
>> I did not realize that either. I think it's kind of a dangerous
>> interface that way.
>
> Its the immediate fallbacks; they can have their own - and a repo can
> have N immediate fallbacks because of shared repositories with stacked
> branches in the repo.
Sure. I would just change it to be called _immediate_
something so that people don't misinterpret it.
> Flattening it is possible, but you want to make sure you still have
> the fallback repositories know their own fallbacks so they can
> maintain their own invariants about inventories, revisions etc. The
> downside if you flatten it then is that you need two apis - a
> non-recursive one and a recursive one, or you'll end up handling
> fallbacks twice - once in the top level, and then once in the first
> level. Of course this can still happen when you have several direct
> fallbacks, but thats very uncommon today.
It seems like either recursing or flattening them can get into
inefficiency. At the moment flattening it from a method call at the
moment we want to know the list seems easiest.
If you get the chance to review
<https:/
appreciate it.
If you have a chance I'd like to see your review of the patch.
Changed in launchpad: | |
assignee: | nobody → William Grant (wgrant) |
status: | New → In Progress |
Changed in launchpad: | |
importance: | Undecided → Critical |
Martin Pool (mbp) wrote : | #11 |
I looked for other cases and couldn't find any. We can make the api a bit safer by renaming it: https:/
This is now waiting for deployment to launchpad, probably in the next 24h.
Changed in bzr: | |
status: | In Progress → Fix Released |
Launchpad QA Bot (lpqabot) wrote : | #12 |
Fixed in stable r12348 <http://
Changed in launchpad: | |
milestone: | none → 11.03 |
tags: | added: qa-needstesting |
Changed in launchpad: | |
status: | In Progress → Fix Committed |
Martin Pool (mbp) wrote : | #13 |
I'm adding a task against udd for deploying a fixed bzr to the importer. It may or may not actually be necessary.
Changed in udd: | |
status: | New → Confirmed |
importance: | Undecided → High |
assignee: | nobody → canonical-bazaar (canonical-bazaar) |
tags: |
added: qa-ok removed: qa-needstesting |
Martin Pool (mbp) wrote : | #14 |
bug 716892 for monitoring to catch similar failures.
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
John A Meinel (jameinel) wrote : | #15 |
So are we still just waiting on this being deployed in order to consider it finished?
John A Meinel (jameinel) wrote : | #16 |
This landed in bzr-2.3 on revision 5622. So it should be included in whatever bzr-2.3.2 release is made.
Changed in udd: | |
status: | Confirmed → Fix Released |
Changed in bzr (Ubuntu): | |
status: | New → Fix Released |
Changed in bzr (Ubuntu Natty): | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Jelmer Vernooij (jelmer) |
Accepted bzr into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https:/
Changed in bzr (Ubuntu Natty): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed |
Martin Pool (mbp) wrote : | #18 |
Hi pitti, thanks for taking this into natty-proposed.
There is a regression in 2.3.3 which should block the SRU, bug 786980. We will fix that and then try again with 2.3.4.
tags: | added: sru |
tags: |
added: verification-failed removed: verification-needed |
Martin Pool (mbp) wrote : | #19 |
(I've marked this verification-failed to abort the SRU; this particular bug is actually fine afaik.)
Clint Byrum (clint-fewbar) wrote : | #20 |
Hello William, or anyone else affected,
Accepted bzr into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https:/
tags: | removed: verification-failed |
tags: | added: verification-needed |
Jelmer Vernooij (jelmer) wrote : | #21 |
Verified by running the bzr testsuite from the package in a clean natty install.
tags: |
added: verification-done removed: verification-needed |
Launchpad Janitor (janitor) wrote : | #22 |
This bug was fixed in the package bzr - 2.3.4-0ubuntu1
---------------
bzr (2.3.4-0ubuntu1) natty-proposed; urgency=low
* New upstream release.
+ Fix bzr version number in deprecation warnings. LP: #794960
+ Prevent write attemps on remote branch during "bzr up". LP: #786980
+ Fix conflict handling when two trees involved in a merge have different
root ids. LP: #805809
bzr (2.3.3-0ubuntu1) natty-proposed; urgency=low
* New upstream release.
+ Fixes deprecation warning on newer versions of Python. LP: #760435
+ Stops 'bzr push' from copying entire repository if a .bzr directory is
present without a branch. LP: #465517
+ Fixes undefined local variable error when waiting for lock. LP: #733136
+ Fixes lock contention issues pushing to a bound branch. LP: #733350
+ Transfers less data creating a new stacked branch. LP: #737234
+ Several fixes to the test suite, making it more robust. LP: #654733,
LP: #751824
+ 'bzr merge --pull --preview' actually shows a preview rather than
actually merging. LP: #760152
+ bzr smart server now supports UTF-8 user names. LP: #659763
+ user identity can now be set based on username and /etc/mailname, not
requiring it to be set manually. LP: #616878
+ stacking is now fully transitive. LP: #715000
+ makes in-terminal crash report of plugins much shorter. LP: #716389
-- Jelmer Vernooij <email address hidden> Thu, 14 Jul 2011 21:12:58 +0200
Changed in bzr (Ubuntu Natty): | |
status: | Fix Committed → Fix Released |
tags: | removed: verification-done |
Martin Pitt (pitti) wrote : | #23 |
Is there really much point in fixing this in maverick now? It has lived most of its live with this bug, and will go EOL in two months.
Changed in bzr (Ubuntu Maverick): | |
status: | New → Won't Fix |
Seems to be Branch. iter_merge_ sorted_ revisions that is common to both here,
so may just be limited to that one code path.
Thanks,
James