mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-05 08:47:56 +01:00
Code Activity
git/t/t9137-git-svn-dcommit-clobber-series.sh

64 lines
1.7 KiB
Bash
Raw Normal View History

git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
#!/bin/sh
#
# Copyright (c) 2007 Eric Wong
t/t91XX git-svn tests: run "git svn" not "git-svn" This replaces 'git-svn' with 'git svn' in the tests. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-08 12:02:08 +02:00
test_description='git svn dcommit clobber series'
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
. ./lib-git-svn.sh
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
test_expect_success 'initialize repo' '
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
mkdir import &&
cd import &&
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
awk "BEGIN { for (i = 1; i < 64; i++) { print i } }" > file
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd import -m "initial" . "$svnrepo" &&
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
cd .. &&
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
git svn init "$svnrepo" &&
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
git svn fetch &&
test -e file
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
'
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
test_expect_success '(supposedly) non-conflicting change from SVN' '
test x"`sed -n -e 58p < file`" = x58 &&
test x"`sed -n -e 61p < file`" = x61 &&
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd co "$svnrepo" tmp &&
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
cd tmp &&
Fix use of "perl -i" on Windows The perldiag(1) has following to say about this: "Can't do inplace edit without backup" (F) You're on a system such as MS-DOS that gets confused if you try reading from a deleted (but still opened) file. You have to say -i.bak, or some such. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-25 20:35:13 +02:00
perl -i.bak -p -e "s/^58$/5588/" file &&
perl -i.bak -p -e "s/^61$/6611/" file &&
t9106: fix a race condition that caused svn to miss modifications carbonated beverage noticed this test was occasionally failing. Signed-off-by: Eric Wong <normalperson@yhbt.net>
2007-11-21 09:57:33 +01:00
poke file &&
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
test x"`sed -n -e 58p < file`" = x5588 &&
test x"`sed -n -e 61p < file`" = x6611 &&
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd commit -m "58 => 5588, 61 => 6611" &&
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
cd ..
Fix tests breaking when checkout path contains shell metacharacters This fixes the remainder of the issues where the test script itself is at fault for failing when the git checkout path contains whitespace or other shell metacharacters. The majority of git svn tests used the idiom test_expect_success "title" "test script using $svnrepo" These were changed to have the test script in single-quotes: test_expect_success "title" 'test script using "$svnrepo"' which unfortunately makes the patch appear larger than it really is. One consequence of this change is that in the verbose test output the value of $svnrepo (and in some cases other variables, too) is no longer expanded, i.e. previously we saw * expecting success: test script using /path/to/git/t/trash/svnrepo but now it is: * expecting success: test script using "$svnrepo" Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-04 07:37:59 +02:00
'
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
test_expect_success 'some unrelated changes to git' "
echo hi > life &&
git update-index --add life &&
git commit -m hi-life &&
echo bye >> life &&
git commit -m bye-life life
"
test_expect_success 'change file but in unrelated area' "
test x\"\`sed -n -e 4p < file\`\" = x4 &&
test x\"\`sed -n -e 7p < file\`\" = x7 &&
Fix use of "perl -i" on Windows The perldiag(1) has following to say about this: "Can't do inplace edit without backup" (F) You're on a system such as MS-DOS that gets confused if you try reading from a deleted (but still opened) file. You have to say -i.bak, or some such. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-25 20:35:13 +02:00
perl -i.bak -p -e 's/^4\$/4444/' file &&
perl -i.bak -p -e 's/^7\$/7777/' file &&
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
test x\"\`sed -n -e 4p < file\`\" = x4444 &&
test x\"\`sed -n -e 7p < file\`\" = x7777 &&
git commit -m '4 => 4444, 7 => 7777' file &&
git svn dcommit &&
git-svn testsuite: use standard configuration for Subversion tools I have tweaked configuration in my ~/.subversion directory, namely I am running auto-properties and automatically adding '$Id$' expansion to every file. This choke the last test named 'proplist' from t9101-git-svn-props.sh, because one more property, svn:keywords is automatically added. I had just wrapped svn invocation with the svn_cmd that specifies empty directory via --config-dir argument. Since the latter is the global option, it should be recognized by all svn subcommands, so no regressions will be introduced. Now svn_cmd is used everywhere, not just in the failed test module: this should guard us from the future clashes with user-defined configuration tweaks. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Acked-by: Eric Wong <normalperson@yhbt.net>
2009-05-08 10:06:16 +02:00
svn_cmd up tmp &&
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
cd tmp &&
test x\"\`sed -n -e 4p < file\`\" = x4444 &&
test x\"\`sed -n -e 7p < file\`\" = x7777 &&
test x\"\`sed -n -e 58p < file\`\" = x5588 &&
test x\"\`sed -n -e 61p < file\`\" = x6611
"
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 'attempt to dcommit with a dirty index' '
git-svn: prevent dcommitting if the index is dirty. dcommit uses rebase to sync the history with what has just been pushed to SVN. Trying to dcommit with a dirty index is troublesome for rebase, so now the user will get an error message if he attempts to dcommit with a dirty index. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-11 19:41:41 +01:00
echo foo >>file &&
git add file &&
t/: Use "test_must_fail git" instead of "! git" This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-12 17:47:52 +02:00
test_must_fail git svn dcommit
git-svn: prevent dcommitting if the index is dirty. dcommit uses rebase to sync the history with what has just been pushed to SVN. Trying to dcommit with a dirty index is troublesome for rebase, so now the user will get an error message if he attempts to dcommit with a dirty index. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-11 19:41:41 +01:00
'
git-svn: fix dcommit clobbering when committing a series of diffs Our revision number sent to SVN is set to the last revision we committed if we've made any previous commits in a dcommit invocation. Although our SVN Editor code uses the delta of two (old) trees to generate information to send upstream, it'll still send complete resultant files upstream; even if the tree they're based against is out-of-date. The combination of sending a file that does not include the latest changes, but set with a revision number of a commit we just made will cause SVN to accept the resultant file even if it was generated against an old tree. More trouble was caused when fixing this because we were rebasing uncessarily at times. We used git-diff-tree to check the imported SVN revision against our HEAD, not the last tree we committed to SVN. The unnecessary rebasing caused merge commits upstream to SVN to fail. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 12:21:47 +01:00
test_done
Copy permalink