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

[Pazu <pazu@pazu.com.br>]

Seth Falcon wrote:

> 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
> :-\

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