1

我们的代码是 C++ 并且在 svn 中管理。开发是使用 Visual Studio 进行的。如您所知，Visual Studio C++ 对文件名不区分大小写，不幸的是我们的代码“利用”了这一点。

不，我们正在将我们的应用程序移植到区分大小写的 Linux + gcc。这将涉及大量文件名和文件更改。我们计划在单独的分支中进行开发。

看来 svn rename 有一个众所周知的问题（这里和这里）。有没有办法解决它？git-svn 或 svnmerge 可以在这里提供帮助吗？

谢谢迪玛

4

4 回答 4

4

区分大小写的问题不在于 Visual Studio 与 GCC，而在于文件系统；Windows 和 Mac OS X 上的标准文件系统（Windows 为 FAT32 和 NTFS，Mac OS X 为 HFS+）不区分大小写但保留大小写，而 Linux 文件系统（ext2、ext3 和 ext4）区分大小写。我建议您重命名文件，对所有源文件使用全部小写，然后进行分支，并且 - 当然 - 对于未来，有一个严格的使用小写和“.cpp”扩展名的策略所有 C++ 源文件和所有头文件的“.h”。是否有任何原因您不能在分支之前执行此重命名？

于 2009-08-04T07:46:25.793 回答
3

Git 本身（非常好）通过进行启发式文件内容和基于文件名相似性的重命名检测来解决合并中重命名文件的问题（而不仅仅是在那里）。它不需要像重命名跟踪解决方案那样输入有关重命名的信息。

于 2009-08-04T07:39:54.010 回答
1

这里有两个问题，一个是 svn 对重命名和合并的限制，在我看来，一旦决定使用 svn 进行项目，不建议在中间切换版本控制软件。我会与其他开发人员交谈，并循环锁定整个项目并进行重命名。

就我而言，我用一个简单的 perl 脚本解决了头文件区分大小写的问题：它将修复回车并将包含设置为小写。注释部分修复了包含。

#!/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, ".");
于 2009-08-04T08:26:31.687 回答
1

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

于 2009-08-04T17:12:35.757 回答