1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-05 08:47:56 +01:00
git/t/t9151/make-svnmerge-dump

162 lines
4.1 KiB
Text
Raw Normal View History

#!/bin/sh
#
# this script sets up a Subversion repository for Makefile in the
# first ever git merge, as if it were done with svnmerge (SVN 1.5+)
#
rm -rf foo.svn foo
set -e
mkdir foo.svn
svnadmin create foo.svn
svn co file://`pwd`/foo.svn foo
commit() {
i=$(( $1 + 1 ))
shift;
svn commit -m "(r$i) $*" >/dev/null || exit 1
echo $i
}
say() {
echo " * $*"
}
i=0
cd foo
mkdir trunk
mkdir branches
svn add trunk branches
i=$(commit $i "Setup trunk and branches")
git cat-file blob 6683463e:Makefile > trunk/Makefile
svn add trunk/Makefile
say "Committing ANCESTOR"
i=$(commit $i "ancestor")
svn cp trunk branches/left
say "Committing BRANCH POINT"
i=$(commit $i "make left branch")
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
svn cp trunk branches/right
say "Committing other BRANCH POINT"
i=$(commit $i "make right branch")
say "Committing LEFT UPDATE"
git cat-file blob 5873b67e:Makefile > branches/left/Makefile
i=$(commit $i "left update 1")
git cat-file blob 75118b13:Makefile > branches/right/Makefile
say "Committing RIGHT UPDATE"
pre_right_update_1=$i
i=$(commit $i "right update 1")
say "Making more commits on LEFT"
git cat-file blob ff5ebe39:Makefile > branches/left/Makefile
i=$(commit $i "left update 2")
git cat-file blob b5039db6:Makefile > branches/left/Makefile
i=$(commit $i "left update 3")
say "Making a LEFT SUB-BRANCH"
svn cp branches/left branches/left-sub
sub_left_make=$i
i=$(commit $i "make left sub-branch")
say "Making a commit on LEFT SUB-BRANCH"
echo "crunch" > branches/left-sub/README
svn add branches/left-sub/README
i=$(commit $i "left sub-branch update 1")
say "Merging LEFT to TRUNK"
svn update
cd trunk
svn merge ../branches/left --accept postpone
git cat-file blob b5039db6:Makefile > Makefile
svn resolved Makefile
i=$(commit $i "Merge left to trunk 1")
cd ..
say "Making more commits on LEFT and RIGHT"
echo "touche" > branches/left/zlonk
svn add branches/left/zlonk
i=$(commit $i "left update 4")
echo "thwacke" > branches/right/bang
svn add branches/right/bang
i=$(commit $i "right update 2")
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
say "Squash merge of RIGHT tip 2 commits onto TRUNK"
svn update
cd trunk
svn merge -r$pre_right_update_1:$i ../branches/right
i=$(commit $i "Cherry-pick right 2 commits to trunk")
cd ..
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
say "Merging RIGHT to TRUNK"
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
svn update
cd trunk
svn merge ../branches/right --accept postpone
git cat-file blob b51ad431:Makefile > Makefile
svn resolved Makefile
i=$(commit $i "Merge right to trunk 1")
cd ..
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
say "Making more commits on RIGHT and TRUNK"
echo "whamm" > branches/right/urkkk
svn add branches/right/urkkk
i=$(commit $i "right update 3")
echo "pow" > trunk/vronk
svn add trunk/vronk
i=$(commit $i "trunk update 1")
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
say "Merging RIGHT to LEFT SUB-BRANCH"
svn update
cd branches/left-sub
svn merge ../right --accept postpone
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
git cat-file blob b51ad431:Makefile > Makefile
svn resolved Makefile
i=$(commit $i "Merge right to left sub-branch")
cd ../..
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 <normalperson@yhbt.net>
2009-11-14 22:26:47 +01:00
say "Making more commits on LEFT SUB-BRANCH and LEFT"
echo "zowie" > branches/left-sub/wham_eth
svn add branches/left-sub/wham_eth
pre_sub_left_update_2=$i
i=$(commit $i "left sub-branch update 2")
sub_left_update_2=$i
echo "eee_yow" > branches/left/glurpp
svn add branches/left/glurpp
i=$(commit $i "left update 5")
say "Cherry pick LEFT SUB-BRANCH commit to LEFT"
svn update
cd branches/left
svn merge -r$pre_sub_left_update_2:$sub_left_update_2 ../left-sub
i=$(commit $i "Cherry-pick left sub-branch commit to left")
cd ../..
say "Merging LEFT SUB-BRANCH back to LEFT"
svn update
cd branches/left
# it's only a merge because the previous merge cherry-picked the top commit
svn merge -r$sub_left_make:$sub_left_update_2 ../left-sub --accept postpone
i=$(commit $i "Merge left sub-branch to left")
cd ../..
say "Merging EVERYTHING to TRUNK"
svn update
cd trunk
svn merge ../branches/left --accept postpone
svn resolved bang
i=$(commit $i "Merge left to trunk 2")
# this merge, svn happily updates the mergeinfo, but there is actually
# nothing to merge. git-svn will not make a meaningless merge commit.
svn merge ../branches/right --accept postpone
i=$(commit $i "non-merge right to trunk 2")
cd ..
cd ..
svnadmin dump foo.svn > svn-mergeinfo.dump
rm -rf foo foo.svn