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

From: Pazu <pazu@pazu.com.br>
Date: Oct 10, 2006, 02:11 UTC
Message-ID: <egevhe$d15$1@sea.gmane.org>
In-Reply-To: <m2psd1rwb0.fsf@ziti.local>

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