svn rename problem

Question

Our code is C++ and is managed in svn. The development is with Visual Studio. As you know Visual Studio C++ is case insensitive to file names and our code unfortunately "exploited" this heavily.

No we are porting our application to Linux + gcc, which is case sensitive. This will involve a lot of file names and file changes. We planned to do the development in separate branch.

It appears that svn rename has a well known problem (here and here). Is there a way to workaround it? Is git-svn or svnmerge can aid here?

Thanks Dima

Answer 1

The case sensitivity issue is not about Visual Studio vs. GCC, but rather about the filesystem; the standard filesystems on Windows and Mac OS X (FAT32 and NTFS for Windows, HFS+ for Mac OS X), are case insenstive but case preserving, while Linux filesystems (ext2, ext3, and ext4) are case sensitive. I would suggest that you rename your files, using all lower case for all your source files, and then branch, and -- of course -- for the future, have a strict policy of using lower case and a ".cpp" extension for all C++ source files and ".h" for all header files. Is there any reason you cannot perform this renaming prior to the branch?

Answer 2

Git itself deals (very well) with the problem of renamed files in merges (and not only there) by doing heuristic file-contents and filename similarity based rename detection. It doesn't require to have information about renames entered like rename tracking solution.

Answer 3

There are two questions here, one is the svn limitation on renames and merges, in my opinion once one has decided to go with svn for a project it would not be advisable to switch version control software in the middle. I'd talk to the other developers, and make cycles of locking the whole project and doing the renames.

In my case I solved the case-sensitive problems of the header files with a simple perl script: It will fix carriage returns and set includes to lowercase. The commented part fixes the includes.

#!/usr/bin/perl
use strict;
use warnings;
#
use File::Find;
use File::Copy;

sub wanted
{
    if(  m/\.c$/i || m/\.h$/i ) {
        my $orig = $_;
        my $bak = $orig.".bak";
        my $dst = $orig;
        system("fromdos",$orig) == 0 or die "fromdos: $?";
#       open(FH,'<',$orig) or die "open $orig: $!";
#       my @lines;
#       while(my $line = <FH>) {
#           if( $line =~ m/(^#include\s+")([^"]+)(".*)$/ ) {
#               print $line;
#               my $inc = $2;
#               $inc =~ tr/A-Z/a-z/;
#               print "change to:\n";
#               print $1.$inc.$3."\n";
#               print "\n";
#               push @lines, $1 . $inc . $3."\n";
#           } else {
#               push @lines,$line;
#           }
#       }
#       close(FH);
#       #move($orig,$bak) or die "move $orig to $bak: $!";
#       unlink($orig);
#       open(FH, '>', $dst) or die "open $dst: $!";
#       print FH @lines;
#       close(FH);

    }
}

find(\&wanted, ".");

Answer 4

As others said, the original problem has nothing to do with SCMs, really. As for using git, you could do the merge in git-svn and push it back to the SVN repo - just be aware ahead of time that this is a one-time option, i.e., don't expect SVN to realize that this commit was a merge or even that files were renamed - you'll lose file history unless you're really careful.

As a side note alongside "really careful" option, the only way to make git-svn push correct "file rename" info to svn that seems to work reliably is to rename the files in git-svn without changing any contents, commit, and then modify whatever files you want and do another commit. If you modify the renamed file before committing, git-svn knows that the file has likely been moved but apparently does not trust its own heuristic enough to push this info back to svn. It's quite possible that I'm missing some magical option that makes this work better :)