From: Pazu Date: Tue, 10 Oct 2006 02:11:30 GMT Subject: Re: git-svn fetch fails when a file is renamed changing only case Message-ID: In-Reply-To: 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