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>
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>
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>
Previously, git-svn would ignore cases where the path we're
tracking is removed from the repository. This was to prevent
heads with follow-parent from ending up with a tree full of
empty revisions (and thus breaking rename detection).
The previous behavior is fine until the path we're tracking
is re-added later on, leading to the old files being merged
in with the new files in the directory (because the old
files were never marked as deleted)
We will now only remove all the old files locally that were
deleted remotely iff we detect the directory we're in is being
created from scratch.
Thanks for Marcus D. Hanwell for the bug report and
Peter Baumann for the analysis.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
