我们的代码是C ++,在svn中管理。开发是使用Visual Studio。如您所知,Visual Studio C ++对文件名不区分大小写,我们的代码很遗憾地被“利用”了。
不,我们正在将我们的应用程序移植到Linux + gcc, 区分大小写。这将涉及大量文件名和文件更改。我们计划在独立的分支机构进行开发。
似乎svn重命名有一个众所周知的问题(here和here)。 有办法解决它吗? git-svn或svnmerge可以在这里提供帮助吗?
由于 迪马
答案 0 :(得分:4)
区分大小写问题不是关于Visual Studio与GCC,而是关于文件系统; Windows和Mac OS X上的标准文件系统(适用于Windows的FAT32和NTFS,适用于Mac OS X的HFS +)不区分大小写但保留大小写,而Linux文件系统(ext2,ext3和ext4)区分大小写。我建议你重命名你的文件,使用所有源文件的小写,然后分支,当然 - 对于未来,有一个严格的政策,使用小写和“.cpp”扩展为所有C ++源文件和所有头文件的“.h”。你有什么理由不能在分支之前进行这种重命名吗?
答案 1 :(得分:3)
Git本身通过基于重命名检测的启发式文件内容和文件名相似性来处理合并中(而不仅仅是那里)重命名文件的问题(非常好)。它不需要输入有关重命名的信息,如重命名跟踪解决方案。
答案 2 :(得分:1)
这里有两个问题,一个是关于重命名和合并的svn限制,在我看来,一旦决定使用svn进行项目,在中间切换版本控制软件是不可取的。我会与其他开发人员交谈,并制定锁定整个项目并进行重命名的循环。
在我的情况下,我用一个简单的perl脚本解决了头文件的区分大小写的问题:它将修复回车并将include设置为小写。 注释部分修复了包含。
#!/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, ".");
答案 3 :(得分:1)
正如其他人所说,原始问题与SCM无关,实际上。至于使用git,你可以在git-svn中进行合并并将其推回到SVN repo - 只是提前知道这是一次性选项,即不要指望SVN意识到这个提交是一个合并,甚至文件被重命名 - 你将失去文件历史,除非你真的小心。
作为旁注和“非常小心”的选项,使git-svn将正确的“文件重命名”信息推送到似乎可靠的svn的唯一方法是重命名git-svn中的文件而不更改任何内容,提交,然后修改你想要的任何文件,并做另一个提交。如果您在提交之前修改重命名的文件,git-svn知道该文件已经可能被移动但显然不信任它自己的启发式,足以将此信息推回到svn。我很可能错过了一些让这项工作更好的神奇选项:)