This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
properties.  The problematic case is when there is some commit on an
unrelated branch after the last commit on the merged-from branch.
When SVN records the mergeinfo property, it records the latest
revision in the whole repository, which, in the problematic case, is
not on the branch it is merging from.

To trigger the git-svn bug, we modify t9151 to include two SVN merges,
the second of which has an intervening commit.  The SVN dump was
generated using SVN 1.6.6 (on Debian squeeze amd64).

Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
---
 t/t9151-svn-mergeinfo.sh   |    6 +-
 t/t9151/make-svnmerge-dump |   32 ++++-
 t/t9151/svn-mergeinfo.dump |  386 +++++++++++++++++++++++++++++++++++++-------
 3 files changed, 366 insertions(+), 58 deletions(-)

diff --git a/t/t9151-svn-mergeinfo.sh b/t/t9151-svn-mergeinfo.sh
index 9bee516..0d42c84 100755
--- a/t/t9151-svn-mergeinfo.sh
+++ b/t/t9151-svn-mergeinfo.sh
@@ -15,7 +15,11 @@ test_expect_success 'load svn dump' "
 	git svn fetch --all
 	"
 
-test_expect_success 'svn merges were represented coming in' "
+test_expect_success 'represent svn merges without intervening commits' "
+	[ `git cat-file commit HEAD^1 | grep parent | wc -l` -eq 2 ]
+	"
+
+test_expect_failure 'represent svn merges with intervening commits' "
 	[ `git cat-file commit HEAD | grep parent | wc -l` -eq 2 ]
 	"
 
diff --git a/t/t9151/make-svnmerge-dump b/t/t9151/make-svnmerge-dump
index e35d64d..7e3da75 100644
--- a/t/t9151/make-svnmerge-dump
+++ b/t/t9151/make-svnmerge-dump
@@ -28,6 +28,10 @@ svn cp trunk branches/left
 
 echo "Committing BRANCH POINT"
 svn commit -m "make left branch"
+svn cp trunk branches/right
+
+echo "Committing other BRANCH POINT"
+svn commit -m "make right branch"
 cd branches/left/
 
 #$sm init
@@ -64,7 +68,33 @@ git cat-file blob b51ad431:Makefile > Makefile
 
 svn resolved Makefile
 
-svn commit -m "Merge trunk"
+svn commit -m "Merge trunk ...
[ message continues ]

Hi Toby,

Thanks for this series, acked and squashed into a single commit to avoid
unnecessary bisection failures at git://git.bogomips.org/git-svn

commit 753dc384dc2c4ab3e1049f695425cebf41ff7e6b
Author: Toby Allsopp <toby.allsopp@navman.co.nz>
Date:   Sat Nov 14 13:26:47 2009 -0800

    git svn: handle SVN merges from revisions past the tip of the branch
    
    When recording the revisions that it has merged, SVN sets the top
    revision to be the latest revision in the repository, which is not
    necessarily a revision on the branch that is being merged from.  When
    it is not on the branch, git-svn fails to add the extra parent to
    represent the merge because it relies on finding the commit on the
    branch that corresponds to the top of the SVN merge range.
    
    In order to correctly handle this case, we look for the maximum
    revision less than or equal to the top of the SVN merge range that is
    actually on the branch being merged from.
    
    [ew: This includes the following (squashed) commit to prevent
         errors during bisect:]
    
      Author: Toby Allsopp <toby.allsopp@navman.co.nz>
      Date:   Fri Nov 13 09:48:39 2009 +1300
    
        git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
    
        This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
        properties.  The problematic case is when there is some commit on an
        unrelated branch after the last commit on the merged-from branch.
        When SVN records the mergeinfo property, it records the latest
        revision in the whole repository, which, in the problematic case, is
        not on the branch it is merging from.
    
        To trigger the git-svn bug, we modify t9151 to include two SVN merges,
        the second of which has an intervening commit.  The SVN dump was
        generated using SVN 1.6.6 (on Debian squeeze amd64).
    
    Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
    Acked-by: Eric Wong ...
[ message continues ]

[Dropped Junio from CC]


Great, thanks.  I have no objection to being squashed, but I'm not sure
what you mean by bisection failures.  Does a test_expect_failure cause
problems for bisection?  It appears to be fairly common to introduce a
failing test case and later fix it, e.g. ce06461 then 751c597.  I'd just
like to understand any potential problems with what I did.

Cheers,
Toby.
--

[ message continues ]

Oops.  I didn't even notice you had test_expect_failure there :x
I'll just leave it as is incase somebody has already pulled from me
(other, unrelated patches coming in a few)

-- 
Eric Wong
--

[ message continues ]