'bzr reconcile' doesn't reconcile the branch

Bug #597891 reported by John Szakmeister
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Undecided
Unassigned
Breezy
Triaged
Low
Unassigned

Bug Description

We have a few branches that have ghost revisions, which I think may be the cause of some other issues. I'd like to reconcile the branch, and get rid of the inconsistent parents, but unfortunately, 'bzr reconcile' appears to be a no-op on the branch.

I've attached a branch that I created against a svn repo which has a ghost revision in it. Simple untar it, run 'bzr check', then 'bzr reconcile', then 'bzr check' again and witness no change in output. :-(

Tags: reconcile
Revision history for this message
John Szakmeister (jszakmeister) wrote :
Revision history for this message
Robert Collins (lifeless) wrote :

reconcile doesn't get rid of (and isn't meant to get rid of) ghost revisions.

I would close this as invalid, but I think its a proxy for some other issue you are experiencing, so lets try to dig into that.

What is actually going on?

Changed in bzr:
status: New → Incomplete
Revision history for this message
John Szakmeister (jszakmeister) wrote : Re: [Bug 597891] Re: 'bzr reconcile' doesn't reconcile the branch

On Thu, Jun 24, 2010 at 1:57 AM, Robert Collins
<email address hidden> wrote:
> reconcile doesn't get rid of (and isn't meant to get rid of) ghost
> revisions.

Sure, but there are "inconsistent parents" that it should be re-writing.

> I would close this as invalid, but I think its a proxy for some other
> issue you are experiencing, so lets try to dig into that.

I think it's still valid despite ghosts. Primarily because bzr-svn
introduces them differently than intended.

> What is actually going on?

Here's the actual output:

Checking working tree at '/Users/jszakmeister/tmp/ghosts-ss/bzr/unreconcilable'.
Checking branch at
'file:///Users/jszakmeister/tmp/ghosts-ss/bzr/unreconcilable/'.
Checking repository at
'file:///Users/jszakmeister/tmp/ghosts-ss/bzr/unreconcilable/'.
checked repository <bzrlib.transport.local.LocalTransport
url=file:///Users/jszakmeister/tmp/ghosts-ss/bzr/unreconcilable/>
format RepositoryFormat2a()
     3 revisions
     3 file-ids
     0 unreferenced text versions
     1 ghost revisions
      <email address hidden>
     1 inconsistent parents
      * file2.txt-20100623220121-44a7dz1q7ivlmidc-1 version
<email address hidden> has parents
('<email address hidden>',) but should
have ()
checked branch file:///Users/jszakmeister/tmp/ghosts-ss/bzr/unreconcilable/
format Branch format 7

I have a theory for one of the problems I'm seeing. Right now, I'm
hosting several branches via bzr+http, but I have absolutely zero
support for plain http. Most of the branches are served quite
happily, but a couple insist on failing to branch. When I dug into
things further, the only difference I could find with the branches is
that some of them had ghost revisions, and "inconsistent parents". So
I said, "hey, just for giggles, let me at least make the inconsistent
parents go away." Tried running 'bzr reconcile' on the branch,
checked it with 'bzr check' and it had exactly the same output. I
*know* this used to work, for the inconsistent parents. I've done it,
and several others on-list have done it too. So I believe this is a
regression. At any rate, I'm really curious if the fact that there
are ghosts, and failing to branch are related. On the branches with
these ghosts and inconsistent parents, the client ends up trying to
check the branch format outside the smart server protocol, where it
doesn't bother doing that with the others.

Hope that helps!

Revision history for this message
Robert Collins (lifeless) wrote :

Could you try reconciling the repository? Branches don't actually
store any significant data, so there is nothing (ghost or parent-graph
related) to fix there.

Revision history for this message
John Szakmeister (jszakmeister) wrote :

On Thu, Jun 24, 2010 at 4:50 AM, Robert Collins
<email address hidden> wrote:
> Could you try reconciling the repository? Branches don't actually
> store any significant data, so there is nothing (ghost or parent-graph
> related) to fix there.

How do I do that? It's not a shared repo in this case, so the repo is
within the branch's .bzr folder.

-John

Revision history for this message
John Szakmeister (jszakmeister) wrote :

On Thu, Jun 24, 2010 at 5:02 AM, John Szakmeister <email address hidden> wrote:
[snip]
> How do I do that?  It's not a shared repo in this case, so the repo is
> within the branch's .bzr folder.

I should add that I thought the proper way to do it in this case was
to run it on the branch. It does at least say that it's reconciling
the repository.

-John

Revision history for this message
Robert Collins (lifeless) wrote :

Ok, if it says its reconciling the repo, it should be. Can we get a
copy of the branch/repository to analyse ?

-Rob

Revision history for this message
John Szakmeister (jszakmeister) wrote :

On Thu, Jun 24, 2010 at 5:41 AM, Robert Collins
<email address hidden> wrote:
> Ok, if it says its reconciling the repo, it should be. Can we get a
> copy of the branch/repository to analyse ?

I can't give you the ones we have (sorry!), but I did attach a tarball
to the ticket that exhibits the same issue. Fortunately (or
unfortunately), it's rather easy to create with bzr-svn.

-John

Revision history for this message
John Szakmeister (jszakmeister) wrote :

Hmm... I sent this via email this morning, but it didn't post.

I can't give you the repo we have (sorry!), but I did attach a tarball
to the ticket that exhibits the same issue. Fortunately (or
unfortunately), it's rather easy to create with bzr-svn.

-John

Revision history for this message
John Szakmeister (jszakmeister) wrote :

Ping. Can someone else familiar with the repo backends look at this? I believe it's a regression from previous versions. Thanks!

Revision history for this message
John Szakmeister (jszakmeister) wrote :

Sorry to keep pinging, but I don't want the issue to die as a result of inactivity. Can somebody confirm whether this is a real bug or not? It's been nearly 4 months since reporting it. :-(

Revision history for this message
Martin Pool (mbp) wrote :

Hi John, sorry for the lag.

When I test your tarball with bzr trunk:

mbp@grace% ~/bzr/trunk/bzr reconcile .
Reconciling branch file:///home/mbp/testdata/597891/unreconcilable/
revision_history ok.
Reconciling repository file:///home/mbp/testdata/597891/unreconcilable/
Reconciliation complete.
mbp@grace% ~/bzr/trunk/bzr check .
Checking working tree at '/home/mbp/testdata/597891/unreconcilable'.
Checking branch at 'file:///home/mbp/testdata/597891/unreconcilable/'.
Checking repository at 'file:///home/mbp/testdata/597891/unreconcilable/'.
checked repository file:///home/mbp/testdata/597891/unreconcilable/ format RepositoryFormat2a()
     3 revisions
     3 file-ids
     1 ghost revisions
checked branch file:///home/mbp/testdata/597891/unreconcilable/ format Branch format 7

It seems like this means this issue is fixed?

Revision history for this message
John Szakmeister (jszakmeister) wrote :

Thanks for checking Martin! I suppose you're running off trunk? It still fails for me on the 2.2.x line (I had 2.2.0 and upgraded to 2.2.1). I wonder what fix in trunk would have made this go away? Perhaps it should be back ported?

Revision history for this message
Martin Pool (mbp) wrote :

2.2 tip also succeeds for me like this:

Am I doing something wrong? All I did was untar this and run this command:

mbp@grace% ~/bzr/bzr.2.2/bzr reconcile .
Reconciling branch file:///home/mbp/testdata/597891/unreconcilable/
revision_history ok.
Reconciling repository file:///home/mbp/testdata/597891/unreconcilable/
Reconciliation complete.
bzr: warning: some compiled extensions could not be loaded; see
<https://answers.launchpad.net/bzr/+faq/703>

Revision history for this message
Martin Pool (mbp) wrote :

and just to check, it does also work with the compiled extensions built.

Revision history for this message
John Szakmeister (jszakmeister) wrote :

On Fri, Oct 15, 2010 at 5:56 AM, Martin Pool <email address hidden> wrote:
> 2.2 tip also succeeds for me like this:
>
> Am I doing something wrong?  All I did was untar this and run this
> command:
>
> mbp@grace% ~/bzr/bzr.2.2/bzr reconcile .
> Reconciling branch file:///home/mbp/testdata/597891/unreconcilable/
> revision_history ok.
> Reconciling repository file:///home/mbp/testdata/597891/unreconcilable/
> Reconciliation complete.
> bzr: warning: some compiled extensions could not be loaded; see
> <https://answers.launchpad.net/bzr/+faq/703>

Did you run 'bzr check' afterwards? For me, it still shows an
inconsistent parent, which was fixed in the past:

<email address hidden>:/Users/jszakmeister/tmp/unrec
:: bzr --version
Bazaar (bzr) 2.2.1
  Python interpreter:
/System/Library/Frameworks/Python.framework/Versions/Current/bin/python
2.6.1
  Python standard library:
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
  Platform: Darwin-10.4.0-i386-64bit
  bzrlib: /Users/jszakmeister/Library/Python/2.6/site-packages/bzrlib
  Bazaar configuration: /Users/jszakmeister/.bazaar
  Bazaar log file: /Users/jszakmeister/.bzr.log

Copyright 2005-2010 Canonical Ltd.
http://bazaar.canonical.com/

bzr comes with ABSOLUTELY NO WARRANTY. bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.

Bazaar is part of the GNU Project to produce a free operating system.

<email address hidden>:/Users/jszakmeister/tmp/unrec
:: bzr check unreconcilable/
Checking working tree at '/Users/jszakmeister/tmp/unrec/unreconcilable'.
Checking branch at 'file:///Users/jszakmeister/tmp/unrec/unreconcilable/'.
Checking repository at 'file:///Users/jszakmeister/tmp/unrec/unreconcilable/'.
checked repository
file:///Users/jszakmeister/tmp/unrec/unreconcilable/ format
RepositoryFormat2a()
     3 revisions
     3 file-ids
     1 ghost revisions
     1 inconsistent parents
checked branch file:///Users/jszakmeister/tmp/unrec/unreconcilable/
format Branch format 7

<email address hidden>:/Users/jszakmeister/tmp/unrec
:: bzr reconcile unreconcilable/
Reconciling branch file:///Users/jszakmeister/tmp/unrec/unreconcilable/
revision_history ok.
Reconciling repository file:///Users/jszakmeister/tmp/unrec/unreconcilable/
Reconciliation complete.

<email address hidden>:/Users/jszakmeister/tmp/unrec
:: bzr check unreconcilable/
Checking working tree at '/Users/jszakmeister/tmp/unrec/unreconcilable'.
Checking branch at 'file:///Users/jszakmeister/tmp/unrec/unreconcilable/'.
Checking repository at 'file:///Users/jszakmeister/tmp/unrec/unreconcilable/'.
checked repository
file:///Users/jszakmeister/tmp/unrec/unreconcilable/ format
RepositoryFormat2a()
     3 revisions
     3 file-ids
     1 ghost revisions
     1 inconsistent parents
checked branch file:///Users/jszakmeister/tmp/unrec/unreconcilable/
format Branch format 7

-John

Revision history for this message
John Szakmeister (jszakmeister) wrote :

On Fri, Oct 15, 2010 at 6:21 AM, John Szakmeister <email address hidden> wrote:
> On Fri, Oct 15, 2010 at 5:56 AM, Martin Pool <email address hidden> wrote:
>> 2.2 tip also succeeds for me like this:

Bah, I didn't try tip, I was just using 2.2.1. You're right, 2.2 tip
is succeeding.

-John

Revision history for this message
Martin Pool (mbp) wrote :

On 15 October 2010 21:25, John Szakmeister <email address hidden> wrote:
> On Fri, Oct 15, 2010 at 6:21 AM, John Szakmeister <email address hidden> wrote:
>> On Fri, Oct 15, 2010 at 5:56 AM, Martin Pool <email address hidden> wrote:
>>> 2.2 tip also succeeds for me like this:
>
> Bah, I didn't try tip, I was just using 2.2.1.  You're right, 2.2 tip
> is succeeding.

Yay!

--
Martin

Revision history for this message
John Szakmeister (jszakmeister) wrote :

On Fri, Oct 15, 2010 at 6:25 AM, John Szakmeister <email address hidden> wrote:
> On Fri, Oct 15, 2010 at 6:21 AM, John Szakmeister <email address hidden> wrote:
>> On Fri, Oct 15, 2010 at 5:56 AM, Martin Pool <email address hidden> wrote:
>>> 2.2 tip also succeeds for me like this:
>
> Bah, I didn't try tip, I was just using 2.2.1.  You're right, 2.2 tip
> is succeeding.

It's more interesting than that. I decided to go rev hunting to see
which fix made the problem go away. My installed version of 2.2.1
*doesn't* work. However, if I branch the 2.2, and do 'bzr pull
--overwrite -r tag:bzr-2.2.1 .', and use that version, it *does*
work--when I don't use compiled extensions. It does fail with
compiled extensions. So I headed back to tip (I didn't actually try
the compiled extension), and repeated my test. For me: without
compiled extensions, it works. If I compile the extensions, it
doesn't work. :-(

-John

Revision history for this message
John Szakmeister (jszakmeister) wrote :

On Fri, Oct 15, 2010 at 7:02 AM, John Szakmeister <email address hidden> wrote:
[snip]
> It's more interesting than that.  I decided to go rev hunting to see
> which fix made the problem go away.  My installed version of 2.2.1
> *doesn't* work.  However, if I branch the 2.2, and do 'bzr pull
> --overwrite -r tag:bzr-2.2.1 .', and use that version, it *does*
> work--when I don't use compiled extensions.  It does fail with
> compiled extensions.  So I headed back to tip (I didn't actually try
> the compiled extension), and repeated my test.  For me: without
> compiled extensions, it works.  If I compile the extensions, it
> doesn't work. :-(

I've narrowed it down to the _groupcompress extension. With the
compiled version it fails. If I move it out of the way, it succeeds.
HTH!

-John

Revision history for this message
Martin Pool (mbp) wrote :

That is very helpful. What OS platform are you on, exactly?

- Martin

On 15/10/2010 10:16 PM, "John Szakmeister" <email address hidden> wrote:

On Fri, Oct 15, 2010 at 7:02 AM, John Szakmeister <email address hidden>
wrote:
[snip]

> It's more interesting than that. I decided to go rev hunting to see
> which fix made the problem ...
I've narrowed it down to the _groupcompress extension. With the
compiled version it fails. If I move it out of the way, it succeeds.
HTH!

-John

--
'bzr reconcile' doesn't reconcile the branch
https://bugs.launchpad.net/bugs/597891
You ...

Revision history for this message
John Szakmeister (jszakmeister) wrote :

Mac OS X, Snow Leopard with 64-bit Python.

-John
On Oct 15, 2010 4:31 PM, "Martin Pool" <email address hidden> wrote:
> That is very helpful. What OS platform are you on, exactly?
>
> - Martin
>
> On 15/10/2010 10:16 PM, "John Szakmeister" <email address hidden> wrote:
>
> On Fri, Oct 15, 2010 at 7:02 AM, John Szakmeister <email address hidden>
> wrote:
> [snip]
>
>> It's more interesting than that. I decided to go rev hunting to see
>> which fix made the problem ...
> I've narrowed it down to the _groupcompress extension. With the
> compiled version it fails. If I move it out of the way, it succeeds.
> HTH!
>
>
> -John
>
> --
> 'bzr reconcile' doesn't reconcile the branch
> https://bugs.launchpad.net/bugs/597891
> You ...
>
> --
> 'bzr reconcile' doesn't reconcile the branch
> https://bugs.launchpad.net/bugs/597891
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Bazaar Version Control System: Incomplete
>
> Bug description:
> We have a few branches that have ghost revisions, which I think may be the
cause of some other issues. I'd like to reconcile the branch, and get rid of
the inconsistent parents, but unfortunately, 'bzr reconcile' appears to be a
no-op on the branch.
>
> I've attached a branch that I created against a svn repo which has a ghost
revision in it. Simple untar it, run 'bzr check', then 'bzr reconcile', then
'bzr check' again and witness no change in output. :-(
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/bzr/+bug/597891/+subscribe

Jelmer Vernooij (jelmer)
Changed in bzr:
status: Incomplete → Confirmed
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: added: reconcile
removed: check-for-breezy
Changed in brz:
status: New → Triaged
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.