checkouts/bound branches lose revisions...

[Erik Bågfors]

Yesterday I was doing a demo of bzr and it went something like this
(taken from scrollback in my terminals).

I wanted to "emulate" two different developers so I was using two
different terminals...

Terminal 1
Setup server

: [bagfors@zyrgelkwyt]$ ; mkdir server
: [bagfors@zyrgelkwyt]$ ; cd server/
: [bagfors@zyrgelkwyt]$ ; bzr init-repo repo
: [bagfors@zyrgelkwyt]$ ; cd repo
: [bagfors@zyrgelkwyt]$ ; ls
: [bagfors@zyrgelkwyt]$ ; bzr init trunk
: [bagfors@zyrgelkwyt]$ ; cd ../..

Terminal 1/User 1:

: [bagfors@zyrgelkwyt]$ ; mkdir u1
: [bagfors@zyrgelkwyt]$ ; cd u1
: [bagfors@zyrgelkwyt]$ ; bzr checkout ../server/repo/trunk
: [bagfors@zyrgelkwyt]$ ; cd trunk/
: [bagfors@zyrgelkwyt]$ ; bzr log
: [bagfors@zyrgelkwyt]$ ; cp /etc/hosts .
: [bagfors@zyrgelkwyt]$ ; bzr add
added hosts
: [bagfors@zyrgelkwyt]$ ; bzr ci -m 'added hosts'
added hosts
Committed revision 1.

Terminal 2/User 2:

: [bagfors@zyrgelkwyt]$ ; mkdir u2
: [bagfors@zyrgelkwyt]$ ; cd u2
: [bagfors@zyrgelkwyt]$ ; bzr checkout ../server/repo/trunk/
: [bagfors@zyrgelkwyt]$ ; cd trunk/
: [bagfors@zyrgelkwyt]$ ; ls
hosts

: [bagfors@zyrgelkwyt]$ ; bzr log
------------------------------------------------------------
revno: 1
committer: Erik Bågfors <email address hidden>
branch nick: trunk
timestamp: Tue 2006-05-09 23:55:20 +0200
message:
 added hosts

: [bagfors@zyrgelkwyt]$ ; vi hosts
: [bagfors@zyrgelkwyt]$ ; bzr ci -m online
modified hosts
Committed revision 2.
: [bagfors@zyrgelkwyt]$ ; bzr log|less

Terminal 1/User 1 (Who's on a plane :) )

: [bagfors@zyrgelkwyt]$ ; vi hosts
: [bagfors@zyrgelkwyt]$ ; bzr ci --local -m 'flight'
modified hosts
Committed revision 2.

: [bagfors@zyrgelkwyt]$ ; vi hosts
: [bagfors@zyrgelkwyt]$ ; bzr ci --local -m 'flight2'
modified hosts
Committed revision 3.

#[tis maj 09 23:56:21]:~/tmp/trunk
: [bagfors@zyrgelkwyt]$ ; bzr log
------------------------------------------------------------
revno: 3
committer: Erik Bågfors <email address hidden>
branch nick: trunk
timestamp: Tue 2006-05-09 23:56:20 +0200
message:
 flight2
------------------------------------------------------------
revno: 2
committer: Erik Bågfors <email address hidden>
branch nick: trunk
timestamp: Tue 2006-05-09 23:56:12 +0200
message:
 flight
------------------------------------------------------------
revno: 1
committer: Erik Bågfors <email address hidden>
branch nick: trunk
timestamp: Tue 2006-05-09 23:55:20 +0200
message:
 added hosts

: [bagfors@zyrgelkwyt]$ ; bzr update
All changes applied successfully.
All changes applied successfully.
Updated to revision 2.

: [bagfors@zyrgelkwyt]$ ; bzr log
------------------------------------------------------------
revno: 2
committer: Erik Bågfors <email address hidden>
branch nick: trunk
timestamp: Tue 2006-05-09 23:56:30 +0200
message:
 online
------------------------------------------------------------
revno: 1
committer: Erik Bågfors <email address hidden>
branch nick: trunk
timestamp: Tue 2006-05-09 23:55:20 +0200
message:
 added hosts

: [bagfors@zyrgelkwyt]$ ; bzr st
modified:
 hosts
pending merges:
 Erik Bågfors 2006-05-09 flight2
   Erik Bågfors 2006-05-09 flight

: [bagfors@zyrgelkwyt]$ ; bzr ci -m 'checkin flicgt stuff''
merged hosts
bzr: ERROR: Revision {<email address hidden>}
not present in <bzrlib.knit.KnitVersionedFile object at 0xb77e2cec>.
[Exit 3 ]

After this, I could still commit stuff with bzr unbind, commit the
merge, bind again, and it was all moved to the "server" branch. But
sooner or later I ran into the same thing again. I tried pulling,
updating, pushing, binding and unbinding, but never got rid of it.

I've done this demo several times and have never had this problem
before. Bzr is
: [bagfors@zyrgelkwyt]$ ; bzr version
bzr (bazaar-ng) 0.8
 bzr checkout, revision 1704
 nick: bzr.dev
 revid: <email address hidden>
Copyright 2005, 2006 Canonical Development Ltd.
http://bazaar-ng.org/ <-- shouldn't that change?

I've attached my bzr.log, it contains manybe alittle to much stuff,
but search for me misspelling of "flight" (flicgt) and you should find
the right area in the file.

Anything I can do to help, please tell me. This makes me loose some
trust in bzr and I'm suddenly to scared to put it into production.

[Erik Bågfors (zindar)]

bzr.log

[Martin Pool (mbp)]

I'll look

[Martin Pool (mbp)]

Erik, can you think of anything at all you might have done differently on the time it did fail? Running other commands simultaneously, or interrupting a process, etc?

[Martin Pool (mbp)]

OK, I can reproduce this. Will have a look.

[Martin Pool (mbp)]

The error I got was

bzr: ERROR: Revision {<email address hidden>} not present in <bzrlib.knit.KnitVersion
edFile object at 0xb77fbcac>.

[Erik Bågfors (zindar)]

No, I can't think of anything.

/Erik

ons 2006-05-10 klockan 08:00 +0000 skrev Martin Pool:

> Erik, can you think of anything at all you might have done differently
> on the time it did fail? Running other commands simultaneously, or
> interrupting a process, etc?
>

[Martin Pool (mbp)]

This patch adds a test case that reproduces the problem.

[Martin Pool (mbp)]

Note that in bzr 0.8 these will be heavyweight checkouts; ie they both have a copy of the relevant parts of the repository history. The exception occurs because bzr didn't fetch all the necessary history in to u1's repository before trying to commit the merge.

In my particular case here we needed mbp@hope-20060510113043-745756817b9b47af; this is in u1 but not in u2 or the repo. I would have thought the commit in the heavy checkout would cause the revision information to be both stored in the checkout's repo and also pushed into the master's repo.

Commit in a bound branch normally tries to push the newly created revision into the master branch. This looks correct. This is specifically disabled for local commits.

It is in this push into the master that the exception occurs; the error is that one of the versions we need is not present in the bound branch, u1. And what's more the revision that's missing is the new one that should have just been created.

[Martin Pool (mbp)]

It seems to be failing to push the revision which was just written into the bound branch - perhaps an object in memory is out of date.

So the marginally good news is that in this reproduction it has not lost any revision data, it's just failing to push it where it should go.

[Aaron Bentley (abentley)]

Martin Pool wrote:
> It seems to be failing to push the revision which was just written into the bound branch - perhaps an object in memory is out of date.
>
> So the marginally good news is that in this reproduction it has not lost any revision data, it's just failing to push it where it should go.

Ah. That's probably the cause of a problem I've observed at work. If
you uncommit, then the data will never be pushed, right?

Aaron

[John A Meinel (jameinel)]

Aaron Bentley wrote:
> Martin Pool wrote:
>> It seems to be failing to push the revision which was just written into the bound branch - perhaps an object in memory is out of date.
>>
>> So the marginally good news is that in this reproduction it has not lost any revision data, it's just failing to push it where it should go.
>
> Ah. That's probably the cause of a problem I've observed at work. If
> you uncommit, then the data will never be pushed, right?
>
> Aaron
>

Well, I ran into the bug where I had a bound branch, and after
committing, the public location was missing a text entry, but had the
revision entry. And that was *really* hard to fix, since it isn't as
simple as just pushing again.

John
=:->

[Robert Collins (lifeless)]

On Wed, 2006-05-10 at 16:05 +0000, John A Meinel wrote:
> Aaron Bentley wrote:
> > Martin Pool wrote:
> >> It seems to be failing to push the revision which was just written into the bound branch - perhaps an object in memory is out of date.
> >>
> >> So the marginally good news is that in this reproduction it has not lost any revision data, it's just failing to push it where it should go.
> >
> > Ah. That's probably the cause of a problem I've observed at work. If
> > you uncommit, then the data will never be pushed, right?
> >
> > Aaron
> >
>
> Well, I ran into the bug where I had a bound branch, and after
> committing, the public location was missing a text entry, but had the
> revision entry. And that was *really* hard to fix, since it isn't as
> simple as just pushing again.

That hole was closed before 0.8 : what we are seeing now is the check I
put in being triggered when the same root cause you ran into occurs.

Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Aaron Bentley (abentley)]

John A Meinel wrote:
> Aaron Bentley wrote:
>
>>Martin Pool wrote:
>>
>>>It seems to be failing to push the revision which was just written into the bound branch - perhaps an object in memory is out of date.
>>>
>>>So the marginally good news is that in this reproduction it has not lost any revision data, it's just failing to push it where it should go.
>>
>>Ah. That's probably the cause of a problem I've observed at work. If
>>you uncommit, then the data will never be pushed, right?
>>
>>Aaron
>>
>
>
> Well, I ran into the bug where I had a bound branch, and after
> committing, the public location was missing a text entry, but had the
> revision entry. And that was *really* hard to fix, since it isn't as
> simple as just pushing again.

It's annoying, sure. The reweave-repositories plugin should work, though.

Aaron

[Martin Pool (mbp)]

this is the basic patch that fixes it - we were using the wrong transaction object.

We should add an assertion that fires if you try this - also can clear up some other code in how commits are prepared.

[Martin Pool (mbp)]

Fix committed for 0.8.1 and 0.9