git-svn fetch fails when a file is renamed changing only case

For example, if you had a file named TestFile and it's renamed to TESTFILE, git-svn fails to fetch revisions after the rename.

My perl skills are close to non-existant, so I'm afraid I don't know how to fix this. Attached to this message, however, is a sample svn repository that can reproduce this bug. Just unpack it somewhere (let's say, in /tmp) and try the following:

tar -C /tmp -xzf git-svn-rename-test.tar.gz mkdir test-wc cd test-wc git-svn init file:///tmp/git-svn-rename-test git-svn fetch

The last command will fail after fetching revision #3, where a file named TestFile was renamed to TESTFILE. Here's the stack trace:

svn: 'TestFile' is not under version control
256 at /Users/pazu/bin/git-svn line 2015
         main::safe_qx('svn', 'propget', 'svn:keywords', 
'TestFile@BASE') called at /Users/pazu/bin/git-svn line 2154
         main::svn_propget_base('svn:keywords', 'TestFile') called at 
/Users/pazu/bin/git-svn line 1773
         main::do_update_index('ARRAY(0x180bd68)', 'remove', 'undef') 
called at /Users/pazu/bin/git-svn line 1805
         main::index_changes() called at /Users/pazu/bin/git-svn line 1875
         main::git_commit('HASH(0x180bd98)', 
'c77db38dc752305ba19ebe19b22306551d0f8d52') called at 
/Users/pazu/bin/git-svn line 346
         main::fetch_cmd() called at /Users/pazu/bin/git-svn line 290
         main::fetch() called at /Users/pazu/bin/git-svn line 149

I'm on Mac OS X (Intel) 10.4.8

mini:~ pazu$ uname -a Darwin mini.intranet.ecore.com.br 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386

Git was compiled from the released 1.4.2.3 sources, without any modifications:

mini:~ pazu$ git-svn --version git-svn version 1.4.2.3

If you need more information, you can contact me directly, or just use the list -- I'll be here listening :)

-- Marcus Brito

Pazu <pazu@pazu.com.br> writes:

Does this work for you via svn?  

On OS X, the default is a non case-sensitive filesystem. I use OS X and have encountered issues with case-change-only commits in svn.

IOW, are you sure this is an issue in git-svn and not an issue in filesystem + svn? For example, I think you will also have problems with a repository that contains in the same dir TESTFILE and TestFile :-\

+ seth

Seth Falcon wrote:

If I try something like:

mini:~$ svn mv TESTFILE TestFile

It will fail with a message saying that TestFile already exists, since HFS+ is case insensitive by default:

svn: File 'TestFile' already exists

But keep in mind this is a shared repository, and people working on case-sensitive file systems may rename the file. I can do it too, if I use full URL's (all examples here use the same test repository provided in my first message):

mini:~$ svn mv file:///tmp/git-svn-rename-test/TESTFILE file:///tmp/git-svn-rename-test/TestFile Commited revision 5.

Anyway, when I'm updating a working copy, svn will do the right thing:

mini:~$ svn co -r1 file:///tmp/git-svn-rename-test D git-svn-rename-test/TESTFILE A git-svn-rename-test/TestFile Checked out revision 1.

mini:~$ cd git-svn-rename-test mini:git-svn-rename-test$ svn up -r3 D TestFile A TESTFILE Updated to revision 3.

A rename for svn is just a copy followed by delete, so when updating, TestFile is removed and then recreated as TESTFILE, correctly.

So, to finally answer your question, no, unfortunately I don't think this is purely an svn problem. Yes, I would have problems with two files named TestFile and TESTFILE in the same dir, but that's not what happens in this test case.

Well, I'll keep browsing the git-svn source code, and try to make some sense out of it...

-- Marcus

Pazu wrote:

While doing that I noticed the error happens in a code path that only gets executed when SVN::Core isn't available. So I decided to go through the trouble of manually building and installing the subversion perl bindings, and to my delight, git-svn is working flawlessly now.

Since svn binaries *use* the svn libraries, I still don't think this was subversion's fault, but probably some bug in git-svn parsing svn output. Oh well, using SVN::Core fixed, and git-svn is a lot faster to boot.

-- Marcus

Pazu <pazu@pazu.com.br> wrote:

Ah, the problem is that git-svn relies on git-diff-files and git-ls-files to track changes when using the command-line svn client. git itself is a case-sensitive file-system, but git-svn relies on the working tree if you didn't have the SVN libraries, and successfully stats the 'TestFile' even though it no longer exists (and is replaced by 'TESTFILE').

Good to know that the SVN:: libraries are working for you, though.