push_merged_revisions creates a branch but doesn't push its contents

[Ivan Sagalaev]

I have a checkout of svn trunk and a local feature branch branched from it. The option "push_merged_revisions" is set to True in ~/.bazaar/subversion.conf. When I merge the feature branch into the checkout and then commit it I expect the feature branch to also get pushed under branches/ in the svn repo. However the branch gets *created* under branches/ but its revisions don't get pushed up there.

I'm attaching a shell script reproducing the problem: it creates a brand new svn repo, updates subversion.conf, makes a checkout, a branch, adds a new file "test.txt" under the branch, merges it back into trunk and commits it. After all this svn log says:

------------------------------------------------------------------------
r3 | maniac | 2009-11-22 23:10:07 +0300 (Sun, 22 Nov 2009) | 1 line
Changed paths:
   A /trunk/test.txt

merged feature
------------------------------------------------------------------------
r2 | maniac | 2009-11-22 23:10:06 +0300 (Sun, 22 Nov 2009) | 1 line
Changed paths:
   A /branches/feature (from /trunk:1)

Create new branch.
------------------------------------------------------------------------
r1 | maniac | 2009-11-22 23:10:04 +0300 (Sun, 22 Nov 2009) | 1 line
Changed paths:
   A /branches
   A /tags
   A /trunk

Initial structure
------------------------------------------------------------------------

It is missing an entry with adding "test.txt" under /branches/feature. I expect it to be right after r2. "svn list file:///tmp/svnrepo/branches/feature" also doesn't show the file.

[Jelmer Vernooij (jelmer)]

Thanks, reproduced.

[John Szakmeister (jszakmeister)]

Jelmer, this is looking like it's probably related to the issue I was seeing. In my case, I had several commits on the branch. It appears that all of the commits but the final one were pushed up. As a result, one of the parents of the merged revision is still a ghost, and hence, the reason that it didn't help me at all.

[Gerard Murphy (g-j-murphy)]

I'm seeing this bug too - I'm using Bazaar 2.2.2 with a manually-installed bzr-svn plugin at version 1.0.5dev, running under Mac OS-X Snow Leopard.

I have both 'push_merged_revisions' and 'append_revisions_only' set to True in 'subversion.conf'

If the additional bug reproduction helps, the affected Subversion repository is visible at:-

https://sageserpent-open.googlecode.com/svn

You can view the revision history on the Subversion side at:-

http://code.google.com/p/sageserpent-open/source/list

I have the original Bazaar repository from before roundtripping available with the missing revisions.

If you look in the Subversion repository, you will see branches 'addStaticTypes' and 'workInProgressOnAddingStaticTypes'. In the pristine Bazaar repository before roundtripping, the first branch *pulled* from the second branch to bring it up to 144.1.13; this was followed by *merging* from the first branch into a checkout of the Subversion branch, yielding 146.

Screenshot attached below.

On the other hand, doing 'bzr svn-import' yields a different revision DAG with a ghost and with missing information on the branches pushed up to Subversion - the effect of the inter-branch pull isn't seen with 'workInProgressOnAddingStaticTypes' still stuck at 144.1.8, and the final revision 144.1.13 from the pulled branch is missing (presumably that would have been the ghost revision).

Screenshot attached below.

This final revision 144.1.13 didn't make into the Subversion repository - so this isn't due 'bzr svn-import' failing.
You can see this in the Subversion history between revisions r159 and r160, corresponding to 144.1.12 and 146 respectively.

[Gerard Murphy (g-j-murphy)]

Hmm: while I'm not going to try this yet in case anyone wants to take a look at my example, what if I was to manually push my branches up to Subversion after doing the merge on to the Subversion checkout in my pristine repository?

I could then pull from Subversion into the roundtripped repository (or at least do a 'bzr fetch-ghosts') in the hope of restoring the missing history.

Is this feasible as a workaround?

[Gerard Murphy (g-j-murphy)]

As an update to my last comment, I had to move things forward and so have tried the workaround, manually pushing up the branches 'workInProgressOnAddingStaticTypes' and 'addStaticTypes' to try and 'heal' the Subversion repository.

I then went to my roundtripped Bazaar repository that I had made with 'bzr svn-import' and performed 'bzr fetch-ghosts' on the branch of the 'trunk' Subversion branch and 'bzr pull' on the branches taken from the Subversion forms of 'workInProgressOnAddingStaticTypes' and 'addStaticTypes'.

Success! The history on the roundtripped repository is now correct, corresponding to the pristine repository.