Comment 2 for bug 485601

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Geoff Jacobsen wrote:
> Public bug reported:
>
> This occurs in conjunction with the bzr-svn plugin (version 1.0.0dev)
> and bzr versions 2.0.0 and 2.0.1
>
> I have an original bzr repository which is push into a subversion
> repository. This is done half hourly if there are any changes on the
> original branch. No changes are done on the svn repo other than the
> push.
>
> Eventually there is a branch and merge on the original which results not
> being able to push to svn since a rebase is needed.
>
> At this stage if I "bzr branch" the svn repo and try to pull the
> original into it I get the error (both on Ubuntu and Solaris) also if I
> try a rebase on a "bzr co svn-repo" I get the same error.
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>
>
> ** Tags: bzr-svn
>

 affects bzr-svn

I don't know that it is bzr-svn's fault, but as it is provoking this
situation, I'm including bzr-svn in the bug report.

 affects bzr
 status confirmed
 importance medium

My guess is that there is a bad interaction with ghosts introduced by
bzr-svn that are(n't) getting filled in when fetching from the original
bzr branch.

Just shooting out a possibility, I would guess that you end up with a
revision graph like:

 A
 |\
 B C
 |/|
 D | # pushed to svn
 |\|
 E F
 |/
 G

And fetching from SVN gives you something like:

 A
 |
 B ? #ghost
 |/
 D

Then fetching from the bzr branch tries to fill in only new children,
such as:

 A
 |
 B ? #still a ghost
 |/|
 D |
 |\|
 E F
 |/
 G

And at that point, we fall over. The stream request did not request the
chk pages for C, so the server specifically excludes them.

However, those pages end up also present in F (and not present in D), so
we don't have them locally.

The various failures:

1) The ancestry search sees that we have D, and stops searching. Thus we
never see that we are missing revision "C" locally.

2) The fetch requests revision E F G versus revision D.

3) The remote side translates that into E F G versus C D.

I haven't proven any of this. But basically it is a failure because
bzr-svn introduces a ghost which we then don't fetch. And the current
codebase expects that if you have a revision, you have all of its
ancestry. (Which ghosts violate.) And the chk map code is especially
sensitive to this.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksGucEACgkQJdeBCYSNAAODuACfaKJ085K7Y3dgWrPTZq4vZnf5
UN0AnjVtFsbMON1N0fw9ghHQ+EBpfaJD
=hSov
-----END PGP SIGNATURE-----