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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html