git/t/t9107-git-svn-migrate.sh

137 lines
4.8 KiB
Bash
Raw Normal View History

#!/bin/sh
# Copyright (c) 2006 Eric Wong
test_description='git svn metadata migrations from previous versions'
. ./lib-git-svn.sh
test_expect_success 'setup old-looking metadata' '
cp "$GIT_DIR"/config "$GIT_DIR"/config-old-git-svn &&
mkdir import &&
(
cd import &&
for i in trunk branches/a branches/b tags/0.1 tags/0.2 tags/0.3
do
mkdir -p $i &&
echo hello >>$i/README ||
exit 1
done &&
svn_cmd import -m test . "$svnrepo"
) &&
git svn init "$svnrepo" &&
git svn fetch &&
rm -rf "$GIT_DIR"/svn &&
git update-ref refs/heads/git-svn-HEAD refs/remotes/git-svn &&
git update-ref refs/heads/svn-HEAD refs/remotes/git-svn &&
git update-ref -d refs/remotes/git-svn refs/remotes/git-svn
'
test_expect_success 'git-svn-HEAD is a real HEAD' '
git rev-parse --verify refs/heads/git-svn-HEAD^0
'
svnrepo_escaped=$(echo $svnrepo | sed 's/ /%20/g')
test_expect_success 'initialize old-style (v0) git svn layout' '
mkdir -p "$GIT_DIR"/git-svn/info "$GIT_DIR"/svn/info &&
echo "$svnrepo" > "$GIT_DIR"/git-svn/info/url &&
echo "$svnrepo" > "$GIT_DIR"/svn/info/url &&
git svn migrate &&
! test -d "$GIT_DIR"/git-svn &&
git rev-parse --verify refs/remotes/git-svn^0 &&
git rev-parse --verify refs/remotes/svn^0 &&
test "$(git config --get svn-remote.svn.url)" = "$svnrepo_escaped" &&
test $(git config --get svn-remote.svn.fetch) = \
":refs/remotes/git-svn"
'
test_expect_success 'initialize a multi-repository repo' '
git svn init "$svnrepo" -T trunk -t tags -b branches &&
git config --get-all svn-remote.svn.fetch > fetch.out &&
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 12:57:07 +00:00
grep "^trunk:refs/remotes/origin/trunk$" fetch.out &&
test -n "$(git config --get svn-remote.svn.branches \
"^branches/\*:refs/remotes/origin/\*$")" &&
test -n "$(git config --get svn-remote.svn.tags \
"^tags/\*:refs/remotes/origin/tags/\*$")" &&
git config --unset svn-remote.svn.branches \
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 12:57:07 +00:00
"^branches/\*:refs/remotes/origin/\*$" &&
git config --unset svn-remote.svn.tags \
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 12:57:07 +00:00
"^tags/\*:refs/remotes/origin/tags/\*$" &&
git config --add svn-remote.svn.fetch "branches/a:refs/remotes/origin/a" &&
git config --add svn-remote.svn.fetch "branches/b:refs/remotes/origin/b" &&
for i in tags/0.1 tags/0.2 tags/0.3
do
git config --add svn-remote.svn.fetch \
$i:refs/remotes/origin/$i || return 1
done &&
git config --get-all svn-remote.svn.fetch > fetch.out &&
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 12:57:07 +00:00
grep "^trunk:refs/remotes/origin/trunk$" fetch.out &&
grep "^branches/a:refs/remotes/origin/a$" fetch.out &&
grep "^branches/b:refs/remotes/origin/b$" fetch.out &&
grep "^tags/0\.1:refs/remotes/origin/tags/0\.1$" fetch.out &&
grep "^tags/0\.2:refs/remotes/origin/tags/0\.2$" fetch.out &&
grep "^tags/0\.3:refs/remotes/origin/tags/0\.3$" fetch.out &&
grep "^:refs/remotes/git-svn" fetch.out
'
# refs should all be different, but the trees should all be the same:
test_expect_success 'multi-fetch works on partial urls + paths' '
refs="trunk a b tags/0.1 tags/0.2 tags/0.3" &&
git svn multi-fetch &&
for i in $refs
do
git rev-parse --verify refs/remotes/origin/$i^0 || return 1;
done >refs.out &&
test -z "$(sort <refs.out | uniq -d)" &&
for i in $refs
do
for j in $refs
do
git diff --exit-code refs/remotes/origin/$i \
refs/remotes/origin/$j ||
return 1
done
done
'
test_expect_success 'migrate --minimize on old inited layout' '
git config --unset-all svn-remote.svn.fetch &&
git config --unset-all svn-remote.svn.url &&
rm -rf "$GIT_DIR"/svn &&
for i in $(cat fetch.out)
do
t9107: use shell parameter expansion to avoid breaking &&-chain This test intentionally breaks the &&-chain when using `expr` to parse "[<path>]:<ref>" since the pattern matching operation will return 1 (failure) when <path> is empty even though an empty <path> is legitimate in this test and should not cause the test to fail. However, it is possible to parse the input without breaking the &&-chain by using shell parameter expansion (i.e. `${i%%...}`). Other ways to avoid the problem would be `{ expr $i : ... ||:; }` or test_might_fail(), however, parameter expansion seems simplest. IMPLEMENTATION NOTE The rewritten `if` expression: if test "$ref" = "${ref#refs/remotes/}"`; then continue; fi is perhaps a bit subtle. At first glance, it looks like it will `continue` the loop if $ref starts with "refs/remotes/", but in fact it's the opposite: the loop will `continue` if $ref does not start with "refs/remotes/". In the original, `expr` would only match if the ref started with "refs/remotes/", and $ref would end up empty if it didn't, so `test -z` would `continue` the loop if the ref did not start with "refs/remotes/". With parameter expansion, ${ref#refs/remotes/} attempts to strip "refs/remotes/" from $ref. If it fails, meaning that $ref does not start with "refs/remotes/", then the expansion will just be $ref unchanged, and it will `continue` the loop. On the other hand, if stripping succeeds, meaning that $ref begins with "refs/remotes/", then the expansion will be the value of $ref with "refs/remotes/" removed, hence `continue` will not be taken. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-09 05:11:03 +00:00
path=${i%%:*} &&
ref=${i#*:} &&
if test "$ref" = "${ref#refs/remotes/}"; then continue; fi &&
if test -n "$path"; then path="/$path"; fi &&
mkdir -p "$GIT_DIR"/svn/$ref/info/ &&
echo "$svnrepo"$path >"$GIT_DIR"/svn/$ref/info/url ||
return 1
done &&
git svn migrate --minimize &&
test -z "$(git config -l | grep "^svn-remote\.git-svn\.")" &&
git config --get-all svn-remote.svn.fetch > fetch.out &&
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 12:57:07 +00:00
grep "^trunk:refs/remotes/origin/trunk$" fetch.out &&
grep "^branches/a:refs/remotes/origin/a$" fetch.out &&
grep "^branches/b:refs/remotes/origin/b$" fetch.out &&
grep "^tags/0\.1:refs/remotes/origin/tags/0\.1$" fetch.out &&
grep "^tags/0\.2:refs/remotes/origin/tags/0\.2$" fetch.out &&
grep "^tags/0\.3:refs/remotes/origin/tags/0\.3$" fetch.out &&
grep "^:refs/remotes/git-svn" fetch.out
'
test_expect_success ".rev_db auto-converted to .rev_map.UUID" '
git svn fetch -i trunk &&
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 12:57:07 +00:00
test -z "$(ls "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_db.* 2>/dev/null)" &&
expect="$(ls "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_map.*)" &&
test -n "$expect" &&
rev_db="$(echo $expect | sed -e "s,_map,_db,")" &&
convert_to_rev_db "$expect" "$rev_db" &&
rm -f "$expect" &&
test -f "$rev_db" &&
git svn fetch -i trunk &&
Git 2.0: git svn: Set default --prefix='origin/' if --prefix is not given git-svn by default puts its Subversion-tracking refs directly in refs/remotes/*. This runs counter to Git's convention of using refs/remotes/$remote/* for storing remote-tracking branches. Furthermore, combining git-svn with regular git remotes run the risk of clobbering refs under refs/remotes (e.g. if you have a git remote called "tags" with a "v1" branch, it will overlap with the git-svn's tracking branch for the "v1" tag from Subversion. Even though the git-svn refs stored in refs/remotes/* are not "proper" remote-tracking branches (since they are not covered by a proper git remote's refspec), they clearly represent a similar concept, and would benefit from following the same convention. For example, if git-svn tracks Subversion branch "foo" at refs/remotes/foo, and you create a local branch refs/heads/foo to add some commits to be pushed back to Subversion (using "git svn dcommit), then it is clearly unhelpful of Git to throw warning: refname 'foo' is ambiguous. every time you checkout, rebase, or otherwise interact with the branch. The existing workaround for this is to supply the --prefix=quux/ to git svn init/clone, so that git-svn's tracking branches end up in refs/remotes/quux/* instead of refs/remotes/*. However, encouraging users to specify --prefix to work around a design flaw in git-svn is suboptimal, and not a long term solution to the problem. Instead, git-svn should default to use a non-empty prefix that saves unsuspecting users from the inconveniences described above. This patch will only affect newly created git-svn setups, as the --prefix option only applies to git svn init (and git svn clone). Existing git-svn setups will continue with their existing (lack of) prefix. Also, if anyone somehow prefers git-svn's old layout, they can recreate that by explicitly passing an empty prefix (--prefix "") on the git svn init/clone command line. The patch changes the default value for --prefix from "" to "origin/", updates the git-svn manual page, and fixes the fallout in the git-svn testcases. (Note that this patch might be easier to review using the --word-diff and --word-diff-regex=. diff options.) [ew: squashed description of <= 1.9 behavior into manpage] Suggested-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Eric Wong <normalperson@yhbt.net>
2013-10-11 12:57:07 +00:00
test -z "$(ls "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_db.* 2>/dev/null)" &&
test ! -e "$GIT_DIR"/svn/refs/remotes/origin/trunk/.rev_db &&
test -f "$expect"
'
test_done