git-commit-vandalism/t/t9400-git-cvsserver-server.sh

638 lines
18 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2007 Frank Lichtenheld
#
test_description='git-cvsserver access
tests read access to a git repository with the
cvs CLI client via git-cvsserver server'
. ./test-lib.sh
if ! test_have_prereq PERL; then
skip_all='skipping git cvsserver tests, perl not available'
test_done
fi
cvs >/dev/null 2>&1
if test $? -ne 1
then
skip_all='skipping git-cvsserver tests, cvs not found'
test_done
fi
perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
test_done
}
WORKDIR=$PWD
SERVERDIR=$PWD/gitcvs.git
git_config="$SERVERDIR/config"
CVSROOT=":fork:$SERVERDIR"
CVSWORK="$PWD/cvswork"
CVS_SERVER=git-cvsserver
export CVSROOT CVS_SERVER
rm -rf "$CVSWORK" "$SERVERDIR"
test_expect_success 'setup' '
git config push.default matching &&
echo >empty &&
git add empty &&
git commit -q -m "First Commit" &&
mkdir secondroot &&
( cd secondroot &&
git init &&
touch secondrootfile &&
git add secondrootfile &&
git commit -m "second root") &&
merge: refuse to create too cool a merge by default While it makes sense to allow merging unrelated histories of two projects that started independently into one, in the way "gitk" was merged to "git" itself aka "the coolest merge ever", such a merge is still an unusual event. Worse, if somebody creates an independent history by starting from a tarball of an established project and sends a pull request to the original project, "git merge" however happily creates such a merge without any sign of something unusual is happening. Teach "git merge" to refuse to create such a merge by default, unless the user passes a new "--allow-unrelated-histories" option to tell it that the user is aware that two unrelated projects are merged. Because such a "two project merge" is a rare event, a configuration option to always allow such a merge is not added. We could add the same option to "git pull" and have it passed through to underlying "git merge". I do not have a fundamental opposition against such a feature, but this commit does not do so and instead leaves it as low-hanging fruit for others, because such a "two project merge" would be done after fetching the other project into some location in the working tree of an existing project and making sure how well they fit together, it is sufficient to allow a local merge without such an option pass-through from "git pull" to "git merge". Many tests that are updated by this patch does the pass-through manually by turning: git pull something into its equivalent: git fetch something && git merge --allow-unrelated-histories FETCH_HEAD If somebody is inclined to add such an option, updated tests in this change need to be adjusted back to: git pull --allow-unrelated-histories something Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-18 21:21:09 +01:00
git fetch secondroot master &&
git merge --allow-unrelated-histories FETCH_HEAD &&
git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log" &&
GIT_DIR="$SERVERDIR" git config gitcvs.authdb "$SERVERDIR/auth.db" &&
echo cvsuser:cvGVEarMLnhlA > "$SERVERDIR/auth.db"
'
# note that cvs doesn't accept absolute pathnames
# as argument to co -d
test_expect_success 'basic checkout' \
'GIT_CONFIG="$git_config" cvs -Q co -d cvswork master &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5 | head -n 1))" = "empty/1.1/" &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5 | sed -ne \$p))" = "secondrootfile/1.1/"'
#------------------------
# PSERVER AUTHENTICATION
#------------------------
cat >request-anonymous <<EOF
BEGIN AUTH REQUEST
$SERVERDIR
anonymous
END AUTH REQUEST
EOF
cat >request-git <<EOF
BEGIN AUTH REQUEST
$SERVERDIR
git
END AUTH REQUEST
EOF
cat >login-anonymous <<EOF
BEGIN VERIFICATION REQUEST
$SERVERDIR
anonymous
END VERIFICATION REQUEST
EOF
cat >login-git <<EOF
BEGIN VERIFICATION REQUEST
$SERVERDIR
git
END VERIFICATION REQUEST
EOF
cat >login-git-ok <<EOF
BEGIN VERIFICATION REQUEST
$SERVERDIR
cvsuser
Ah<Z:yZZ30 e
END VERIFICATION REQUEST
EOF
test_expect_success 'pserver authentication' \
'cat request-anonymous | git-cvsserver pserver >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
test_expect_success 'pserver authentication failure (non-anonymous user)' \
'if cat request-git | git-cvsserver pserver >log 2>&1
then
false
else
true
fi &&
sed -ne \$p log | grep "^I HATE YOU\$"'
test_expect_success 'pserver authentication success (non-anonymous user with password)' \
'cat login-git-ok | git-cvsserver pserver >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
test_expect_success 'pserver authentication (login)' \
'cat login-anonymous | git-cvsserver pserver >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
test_expect_success 'pserver authentication failure (login/non-anonymous user)' \
'if cat login-git | git-cvsserver pserver >log 2>&1
then
false
else
true
fi &&
sed -ne \$p log | grep "^I HATE YOU\$"'
# misuse pserver authentication for testing of req_Root
cat >request-relative <<EOF
BEGIN AUTH REQUEST
gitcvs.git
anonymous
END AUTH REQUEST
EOF
cat >request-conflict <<EOF
BEGIN AUTH REQUEST
$SERVERDIR
anonymous
END AUTH REQUEST
Root $WORKDIR
EOF
test_expect_success 'req_Root failure (relative pathname)' \
'if cat request-relative | git-cvsserver pserver >log 2>&1
then
echo unexpected success
false
else
true
fi &&
tail log | grep "^error 1 Root must be an absolute pathname$"'
test_expect_success 'req_Root failure (conflicting roots)' \
'cat request-conflict | git-cvsserver pserver >log 2>&1 &&
tail log | grep "^error 1 Conflicting roots specified$"'
test_expect_success 'req_Root (strict paths)' \
'cat request-anonymous | git-cvsserver --strict-paths pserver "$SERVERDIR" >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_success 'req_Root failure (strict-paths)' '
! cat request-anonymous |
git-cvsserver --strict-paths pserver "$WORKDIR" >log 2>&1
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
'
test_expect_success 'req_Root (w/o strict-paths)' \
'cat request-anonymous | git-cvsserver pserver "$WORKDIR/" >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_success 'req_Root failure (w/o strict-paths)' '
! cat request-anonymous |
git-cvsserver pserver "$WORKDIR/gitcvs" >log 2>&1
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
'
cat >request-base <<EOF
BEGIN AUTH REQUEST
/gitcvs.git
anonymous
END AUTH REQUEST
Root /gitcvs.git
EOF
test_expect_success 'req_Root (base-path)' \
'cat request-base | git-cvsserver --strict-paths --base-path "$WORKDIR/" pserver "$SERVERDIR" >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_success 'req_Root failure (base-path)' '
! cat request-anonymous |
git-cvsserver --strict-paths --base-path "$WORKDIR" pserver "$SERVERDIR" >log 2>&1
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
'
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false || exit 1
test_expect_success 'req_Root (export-all)' \
'cat request-anonymous | git-cvsserver --export-all pserver "$WORKDIR" >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_success 'req_Root failure (export-all w/o whitelist)' \
'! (cat request-anonymous | git-cvsserver --export-all pserver >log 2>&1 || false)'
test_expect_success 'req_Root (everything together)' \
'cat request-base | git-cvsserver --export-all --strict-paths --base-path "$WORKDIR/" pserver "$SERVERDIR" >log 2>&1 &&
sed -ne \$p log | grep "^I LOVE YOU\$"'
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true || exit 1
#--------------
# CONFIG TESTS
#--------------
test_expect_success 'gitcvs.enabled = false' \
'GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
then
echo unexpected cvs success
false
else
true
fi &&
grep "GITCVS emulation disabled" cvs.log &&
test ! -d cvswork2'
rm -fr cvswork2
test_expect_success 'gitcvs.ext.enabled = true' \
'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
test_cmp cvswork cvswork2'
rm -fr cvswork2
test_expect_success 'gitcvs.ext.enabled = false' \
'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled false &&
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
then
echo unexpected cvs success
false
else
true
fi &&
grep "GITCVS emulation disabled" cvs.log &&
test ! -d cvswork2'
rm -fr cvswork2
test_expect_success 'gitcvs.dbname' \
'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs.%a.%m.sqlite &&
GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
test_cmp cvswork cvswork2 &&
test -f "$SERVERDIR/gitcvs.ext.master.sqlite" &&
cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs.ext.master.sqlite"'
rm -fr cvswork2
test_expect_success 'gitcvs.ext.dbname' \
'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
GIT_DIR="$SERVERDIR" git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite &&
GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
test_cmp cvswork cvswork2 &&
test -f "$SERVERDIR/gitcvs1.ext.master.sqlite" &&
test ! -f "$SERVERDIR/gitcvs2.ext.master.sqlite" &&
cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs1.ext.master.sqlite"'
#------------
# CVS UPDATE
#------------
rm -fr "$SERVERDIR"
cd "$WORKDIR" &&
git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
exit 1
test_expect_success 'cvs update (create new file)' \
'echo testfile1 >testfile1 &&
git add testfile1 &&
git commit -q -m "Add testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.1/" &&
test_cmp testfile1 ../testfile1'
cd "$WORKDIR"
test_expect_success 'cvs update (update existing file)' \
'echo line 2 >>testfile1 &&
git add testfile1 &&
git commit -q -m "Append to testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.2/" &&
test_cmp testfile1 ../testfile1'
cd "$WORKDIR"
#TODO: cvsserver doesn't support update w/o -d
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test_expect_failure "cvs update w/o -d doesn't create subdir (TODO)" '
mkdir test &&
echo >test/empty &&
git add test &&
git commit -q -m "Single Subdirectory" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
Sane use of test_expect_failure Originally, test_expect_failure was designed to be the opposite of test_expect_success, but this was a bad decision. Most tests run a series of commands that leads to the single command that needs to be tested, like this: test_expect_{success,failure} 'test title' ' setup1 && setup2 && setup3 && what is to be tested ' And expecting a failure exit from the whole sequence misses the point of writing tests. Your setup$N that are supposed to succeed may have failed without even reaching what you are trying to test. The only valid use of test_expect_failure is to check a trivial single command that is expected to fail, which is a minority in tests of Porcelain-ish commands. This large-ish patch rewrites all uses of test_expect_failure to use test_expect_success and rewrites the condition of what is tested, like this: test_expect_success 'test title' ' setup1 && setup2 && setup3 && ! this command should fail ' test_expect_failure is redefined to serve as a reminder that that test *should* succeed but due to a known breakage in git it currently does not pass. So if git-foo command should create a file 'bar' but you discovered a bug that it doesn't, you can write a test like this: test_expect_failure 'git-foo should create bar' ' rm -f bar && git foo && test -f bar ' This construct acts similar to test_expect_success, but instead of reporting "ok/FAIL" like test_expect_success does, the outcome is reported as "FIXED/still broken". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-01 10:50:53 +01:00
test ! -d test
'
cd "$WORKDIR"
test_expect_success 'cvs update (subdirectories)' \
'(for dir in A A/B A/B/C A/D E; do
mkdir $dir &&
echo "test file in $dir" >"$dir/file_in_$(echo $dir|sed -e "s#/# #g")" &&
git add $dir;
done) &&
git commit -q -m "deep sub directory structure" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update -d &&
(for dir in A A/B A/B/C A/D E; do
filename="file_in_$(echo $dir|sed -e "s#/# #g")" &&
if test "$(echo $(grep -v ^D $dir/CVS/Entries|cut -d/ -f2,3,5))" = "$filename/1.1/" &&
test_cmp "$dir/$filename" "../$dir/$filename"; then
:
else
echo >failure
fi
done) &&
test ! -f failure'
cd "$WORKDIR"
test_expect_success 'cvs update (delete file)' \
'git rm testfile1 &&
git commit -q -m "Remove testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test -z "$(grep testfile1 CVS/Entries)" &&
test ! -f testfile1'
cd "$WORKDIR"
test_expect_success 'cvs update (re-add deleted file)' \
'echo readded testfile >testfile1 &&
git add testfile1 &&
git commit -q -m "Re-Add testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.4/" &&
test_cmp testfile1 ../testfile1'
cd "$WORKDIR"
test_expect_success 'cvs update (merge)' \
'echo Line 0 >expected &&
for i in 1 2 3 4 5 6 7
do
echo Line $i >>merge
echo Line $i >>expected
done &&
echo Line 8 >>expected &&
git add merge &&
git commit -q -m "Merge test (pre-merge)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep merge CVS/Entries|cut -d/ -f2,3,5))" = "merge/1.1/" &&
test_cmp merge ../merge &&
( echo Line 0; cat merge ) >merge.tmp &&
mv merge.tmp merge &&
cd "$WORKDIR" &&
echo Line 8 >>merge &&
git add merge &&
git commit -q -m "Merge test (merge)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
sleep 1 && touch merge &&
GIT_CONFIG="$git_config" cvs -Q update &&
test_cmp merge ../expected'
cd "$WORKDIR"
cat >expected.C <<EOF
<<<<<<< merge.mine
Line 0
=======
LINE 0
>>>>>>> merge.1.3
EOF
for i in 1 2 3 4 5 6 7 8
do
echo Line $i >>expected.C
done
test_expect_success 'cvs update (conflict merge)' \
'( echo LINE 0; cat merge ) >merge.tmp &&
mv merge.tmp merge &&
git add merge &&
git commit -q -m "Merge test (conflict)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update &&
test_cmp merge ../expected.C'
cd "$WORKDIR"
test_expect_success 'cvs update (-C)' \
'cd cvswork &&
GIT_CONFIG="$git_config" cvs -Q update -C &&
test_cmp merge ../merge'
cd "$WORKDIR"
test_expect_success 'cvs update (merge no-op)' \
'echo Line 9 >>merge &&
cp merge cvswork/merge &&
git add merge &&
git commit -q -m "Merge test (no-op)" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
sleep 1 && touch merge &&
GIT_CONFIG="$git_config" cvs -Q update &&
test_cmp merge ../merge'
cd "$WORKDIR"
test_expect_success 'cvs update (-p)' '
touch really-empty &&
echo Line 1 > no-lf &&
printf "Line 2" >> no-lf &&
git add really-empty no-lf &&
git commit -q -m "Update -p test" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs update &&
for i in merge no-lf empty really-empty; do
t9400-git-cvsserver-server: don't rely on the output of 'test_cmp' The test 'cvs update (-p)' redirects and checks 'test_cmp's stdout and even its stderr. The commit introducing this test in 6e8937a084 (cvsserver: Add test for update -p, 2008-03-27) doesn't discuss why, in fact its log message only consists of that subject line. Anyway, weird as it is, it kind of made sense due to the way that test was structured: After a bit of preparation, this test updates four files via CVS and checks their contents using 'test_cmp', but it does so in a for loop iterating over the names of those four files. Now, the exit status of a for loop is the exit status of the last command executed in the loop, meaning that the test can't simply rely on the exit code of 'test_cmp' in the loop's body. Instead, the test works it around by relying on the stdout of 'test_cmp' being silent on success and showing the diff on failure, as it appends the stdout of all four 'test_cmp' invocations to a single file and checks that file's emptiness after the loop (with 'test -z "$(cat ...)"', no less; there was no 'test_must_be_empty' back then). Furthermore, the test redirects the stderr of those 'test_cmp' invocations to this file, too: while 'test_cmp' itself doesn't output anything to stderr, the invoked 'diff' or 'cmp' commands do send their error messages there, e.g. if they can't open a file because its name was misspelled. This also makes this test fail when the test script is run with '-x' tracing (and using a shell other than a Bash version supporting BASH_XTRACEFD), because 'test_cmp's stderr contains the trace of the 'diff' command executed inside the helper function, throwing off the subsequent emptiness check. Stop relying on 'test_cmp's output and instead run 'test_cmp a b || return 1' in the for loop in order to make 'test_cmp's error code fail the test. Furthermore, add the missing && after the cvs command to create a && chain in the loop's body. After this change t9400 passes with '-x', even when running with /bin/sh. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-08 23:44:58 +01:00
GIT_CONFIG="$git_config" cvs update -p "$i" >$i.out &&
test_cmp $i.out ../$i || return 1
done
'
cd "$WORKDIR"
test_expect_success 'cvs update (module list supports packed refs)' '
GIT_DIR="$SERVERDIR" git pack-refs --all &&
GIT_CONFIG="$git_config" cvs -n up -d 2> out &&
grep "cvs update: New directory \`master'\''" < out
'
#------------
# CVS STATUS
#------------
cd "$WORKDIR"
test_expect_success 'cvs status' '
mkdir status.dir &&
echo Line > status.dir/status.file &&
echo Line > status.file &&
git add status.dir status.file &&
git commit -q -m "Status test" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
GIT_CONFIG="$git_config" cvs update &&
GIT_CONFIG="$git_config" cvs status | grep "^File: status.file" >../out &&
test_line_count = 2 ../out
'
cd "$WORKDIR"
test_expect_success 'cvs status (nonrecursive)' '
cd cvswork &&
GIT_CONFIG="$git_config" cvs status -l | grep "^File: status.file" >../out &&
test_line_count = 1 ../out
'
cd "$WORKDIR"
test_expect_success 'cvs status (no subdirs in header)' '
cd cvswork &&
GIT_CONFIG="$git_config" cvs status | grep ^File: >../out &&
! grep / <../out
'
#------------
# CVS CHECKOUT
#------------
cd "$WORKDIR"
test_expect_success 'cvs co -c (shows module database)' '
GIT_CONFIG="$git_config" cvs co -c > out &&
grep "^master[ ][ ]*master$" <out &&
! grep -v "^master[ ][ ]*master$" <out
'
#------------
# CVS LOG
#------------
# Known issues with git-cvsserver current log output:
# - Hard coded "lines: +2 -3" placeholder, instead of real numbers.
# - CVS normally does not internally add a blank first line
# or a last line with nothing but a space to log messages.
# - The latest cvs 1.12.x server sends +0000 timezone (with some hidden "MT"
# tagging in the protocol), and if cvs 1.12.x client sees the MT tags,
# it converts to local time zone. git-cvsserver doesn't do the +0000
# or the MT tags...
# - The latest 1.12.x releases add a "commitid:" field on to the end of the
# "date:" line (after "lines:"). Maybe we could stick git's commit id
# in it? Or does CVS expect a certain number of bits (too few for
# a full sha1)?
#
# Given the above, expect the following test to break if git-cvsserver's
# log output is improved. The test is just to ensure it doesn't
# accidentally get worse.
sed -e 's/^x//' -e 's/SP$/ /' > "$WORKDIR/expect" <<EOF
x
xRCS file: $WORKDIR/gitcvs.git/master/merge,v
xWorking file: merge
xhead: 1.4
xbranch:
xlocks: strict
xaccess list:
xsymbolic names:
xkeyword substitution: kv
xtotal revisions: 4; selected revisions: 4
xdescription:
x----------------------------
xrevision 1.4
xdate: __DATE__; author: author; state: Exp; lines: +2 -3
x
xMerge test (no-op)
xSP
x----------------------------
xrevision 1.3
xdate: __DATE__; author: author; state: Exp; lines: +2 -3
x
xMerge test (conflict)
xSP
x----------------------------
xrevision 1.2
xdate: __DATE__; author: author; state: Exp; lines: +2 -3
x
xMerge test (merge)
xSP
x----------------------------
xrevision 1.1
xdate: __DATE__; author: author; state: Exp; lines: +2 -3
x
xMerge test (pre-merge)
xSP
x=============================================================================
EOF
expectStat="$?"
cd "$WORKDIR"
test_expect_success 'cvs log' '
cd cvswork &&
test x"$expectStat" = x"0" &&
GIT_CONFIG="$git_config" cvs log merge >../out &&
sed -e "s%2[0-9][0-9][0-9]/[01][0-9]/[0-3][0-9] [0-2][0-9]:[0-5][0-9]:[0-5][0-9]%__DATE__%" ../out > ../actual &&
test_cmp ../expect ../actual
'
#------------
# CVS ANNOTATE
#------------
cd "$WORKDIR"
test_expect_success 'cvs annotate' '
cd cvswork &&
GIT_CONFIG="$git_config" cvs annotate merge >../out &&
sed -e "s/ .*//" ../out >../actual &&
for i in 3 1 1 1 1 1 1 1 2 4; do echo 1.$i; done >../expect &&
test_cmp ../expect ../actual
'
#------------
# running via git-shell
#------------
cd "$WORKDIR"
test_expect_success 'create remote-cvs helper' '
write_script remote-cvs <<-\EOF
exec git shell -c "cvs server"
EOF
'
test_expect_success 'cvs server does not run with vanilla git-shell' '
(
cd cvswork &&
CVS_SERVER=$WORKDIR/remote-cvs &&
export CVS_SERVER &&
test_must_fail cvs log merge
)
'
test_expect_success 'configure git shell to run cvs server' '
mkdir "$HOME"/git-shell-commands &&
write_script "$HOME"/git-shell-commands/cvs <<-\EOF &&
if ! test $# = 1 && test "$1" = "server"
then
echo >&2 "git-cvsserver only handles \"server\""
exit 1
fi
exec git cvsserver server
EOF
# Should not be used, but part of the recommended setup
write_script "$HOME"/git-shell-commands/no-interactive-login <<-\EOF
echo Interactive login forbidden
EOF
'
test_expect_success 'cvs server can run with recommended config' '
(
cd cvswork &&
CVS_SERVER=$WORKDIR/remote-cvs &&
export CVS_SERVER &&
cvs log merge
)
'
test_done