/tools/perf/scripts/python/bin/

url\E/*##; push @repo_path_split_cache, qr/^(\Q$url\E)/; return ($url, $full_url); Somehow connecting to a repository with the full url makes the returned SVN::Ra object act strangely and break things, so now we just drop the SVN::Ra object that we made our initial connection with. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 2006-08-11git-sh-setup: do not use repo-config to test the git directoryJunio C Hamano1-8/+3 Since repo-config does not fail in non-git directory, it is not a good command to use to test the git-ness nor validate the repository revision of $GIT_DIR. Original patch by Robert Shearman but with minor fixes. Signed-off-by: Junio C Hamano <junkio@cox.net> 2006-08-11git-svn: bugfix: allow SVN:: lib users to track the root of the repositoryEric Wong1-1/+4 I'm not sure if anybody has hit this (besides me), but this fixes the problem where I ran into while attempting to import a small repo at the root level: I ended up with all the commits, but with no file/tree changes at all throughout the entire history. Also, fix a warning if the commit message is not defined for revision 0. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 2006-08-11git-svn: correctly kill keyword expansion without munging EOLsEric Wong1-41/+4 This bugfix applies to users of the svn command-line client only. We no longer muck with newlines when killing keyword expansion. This tended to generate unintended diffs in commits because svn revert -R would destroy the manual EOL changes we were doing. Of course, we didn't need the EOL munging in the first place, as svn seems to do it for us even in the text-base files. Now we set the mtime and atime the files changed by keyword expansion killing to avoid triggering a change on svn revert, which svn still seems to want to do. Thanks to Seth Falcon for reporting this bug. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net> 2006-08-11drop length argument of has_extensionRene Scharfe8-10/+11 As Fredrik points out the current interface of has_extension() is potentially confusing. Its parameters include both a nul-terminated string and a length-limited string. This patch drops the length argument, requiring two nul-terminated strings; all callsites are updated. I checked that all of them indeed provide nul-terminated strings. Filenames need to be nul-terminated anyway if they are to be passed to open() etc. The performance penalty of the additional strlen() is negligible compared to the system calls which inevitably surround has_extension() calls. Additionally, change has_extension() to use size_t inside instead of int, as that is the exact type strlen() returns and memcmp() expects. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>