2009-10-20 04:42:02 +02:00
|
|
|
#!/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
|
|
|
|
|
|
|
|
cd foo
|
|
|
|
mkdir trunk
|
|
|
|
mkdir branches
|
|
|
|
svn add trunk branches
|
|
|
|
svn commit -m "Setup trunk and branches"
|
|
|
|
cd trunk
|
|
|
|
|
|
|
|
git cat-file blob 6683463e:Makefile > Makefile
|
|
|
|
svn add Makefile
|
|
|
|
|
|
|
|
echo "Committing ANCESTOR"
|
|
|
|
svn commit -m "ancestor"
|
|
|
|
cd ..
|
|
|
|
svn cp trunk branches/left
|
|
|
|
|
|
|
|
echo "Committing BRANCH POINT"
|
|
|
|
svn commit -m "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
|
|
|
|
|
|
|
|
echo "Committing other BRANCH POINT"
|
|
|
|
svn commit -m "make right branch"
|
2009-10-20 04:42:02 +02:00
|
|
|
cd branches/left/
|
|
|
|
|
|
|
|
#$sm init
|
|
|
|
#svn commit -m "init svnmerge"
|
|
|
|
|
|
|
|
git cat-file blob 5873b67e:Makefile > Makefile
|
|
|
|
echo "Committing BRANCH UPDATE 1"
|
|
|
|
svn commit -m "left update 1"
|
|
|
|
cd ../..
|
|
|
|
|
|
|
|
cd trunk
|
|
|
|
git cat-file blob 75118b13:Makefile > Makefile
|
|
|
|
echo "Committing TRUNK UPDATE"
|
|
|
|
svn commit -m "trunk update"
|
|
|
|
|
|
|
|
cd ../branches/left
|
|
|
|
git cat-file blob ff5ebe39:Makefile > Makefile
|
|
|
|
echo "Committing BRANCH UPDATE 2"
|
|
|
|
svn commit -m "left update 2"
|
|
|
|
|
|
|
|
git cat-file blob b5039db6:Makefile > Makefile
|
|
|
|
echo "Committing BRANCH UPDATE 3"
|
|
|
|
svn commit -m "left update 3"
|
|
|
|
|
|
|
|
# merge to trunk
|
|
|
|
|
|
|
|
cd ../..
|
|
|
|
svn update
|
|
|
|
cd trunk
|
|
|
|
|
|
|
|
svn merge ../branches/left --accept postpone
|
|
|
|
|
|
|
|
git cat-file blob b51ad431:Makefile > Makefile
|
|
|
|
|
|
|
|
svn resolved Makefile
|
|
|
|
|
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 commit -m "Merge trunk 1"
|
|
|
|
|
|
|
|
# create commits on both branches
|
|
|
|
|
|
|
|
cd ../branches/left
|
|
|
|
git cat-file blob ff5ebe39:Makefile > Makefile
|
|
|
|
echo "Committing BRANCH UPDATE 4"
|
|
|
|
svn commit -m "left update 4"
|
|
|
|
|
|
|
|
cd ../right
|
|
|
|
git cat-file blob b5039db6:Makefile > Makefile
|
|
|
|
echo "Committing other BRANCH UPDATE 1"
|
|
|
|
svn commit -m "right update 1"
|
|
|
|
|
|
|
|
# merge to trun again
|
|
|
|
|
|
|
|
cd ../..
|
|
|
|
svn update
|
|
|
|
cd trunk
|
|
|
|
|
|
|
|
svn merge ../branches/left --accept postpone
|
|
|
|
|
|
|
|
git cat-file blob b51ad431:Makefile > Makefile
|
|
|
|
|
|
|
|
svn resolved Makefile
|
|
|
|
|
|
|
|
svn commit -m "Merge trunk 2"
|
2009-10-20 04:42:02 +02:00
|
|
|
|
|
|
|
cd ../..
|
|
|
|
|
|
|
|
svnadmin dump foo.svn > svn-mergeinfo.dump
|
|
|
|
|
|
|
|
rm -rf foo foo.svn
|