2009-08-04 6 views
1

우리 코드는 C++이며 svn에서 관리됩니다. 개발은 Visual Studio를 사용합니다. 아시다시피 Visual Studio C++은 파일 이름에 대소 문자를 구별합니다. 코드는 불행하게도이를 "많이 사용합니다".svn 이름 바꾸기 문제

아니요 우리는 Linux + gcc에 응용 프로그램을 포팅하지 않습니다. 이며 대소 문자를 구분합니다. 여기에는 많은 파일 이름과 파일 변경이 필요합니다. 우리는 별도의 지점에서 개발을 계획했습니다.

svn rename은 잘 알려진 문제 (herehere)가있는 것으로 보입니다. 해결 방법이 있습니까? git-svn 또는 svnmerge가 여기에서 도움이 될 수 있습니까?

감사 디마

답변

4

대/소문자 구분 문제는 Visual Studio와 GCC가 아니라 파일 시스템에 관한 문제입니다. Windows 및 Mac OS X (Windows의 경우 FAT32 및 NTFS, Mac OS X의 경우 HFS +)의 표준 파일 시스템은 대소 문자를 구분하지 않지만 대소 문자를 보존하며 Linux 파일 시스템 (ext2, ext3 및 ext4)은 대소 문자를 구분합니다. 파일 이름을 바꾸고 모든 소스 파일에 소문자를 사용하고 분기 할 것을 제안합니다. 물론 미래에는 소문자 및 .cpp 확장자에 대해 엄격한 정책을 적용해야합니다. 모든 C++ 소스 파일과 모든 헤더 파일에 대한 ".h". 지점 이전에이 이름 바꾸기를 수행 할 수없는 이유가 있습니까?

+0

이것은 우리가 고려하고있는 것입니다. SCM 도구가 파일 이름 변경에 대한 작업 정책을 강요하지 않으면 SCM 도구의 "필수"작업이됩니다. – dimba

3

힘내 자체는 휴리스틱 파일 내용과 파일 이름의 유사성을 기반으로 이름 변경 감지을 수행하여 병합 (및뿐만 아니라이)에서 이름을 바꾼 파일의 문제를 (잘) 다룹니다. 이름 바꾸기 추적 솔루션처럼 입력 한 이름 변경에 대한 정보가 필요하지 않습니다.

+1

세상에! 그건 p ** 쉬운 ... – flq

1

여기에는 두 가지 질문이 있습니다. 하나는 svn의 이름 변경 및 병합 제한이며, 내 생각에는 프로젝트 용 svn을 사용하기로 결정하면 중간에 버전 제어 소프트웨어를 전환하지 않는 것이 좋습니다. 나는 다른 개발자들과 이야기하고 전체 프로젝트를 잠그고 이름을 바꾸는 사이클을 반복한다.

필자는 필자가 간단한 펄 스크립트를 사용하여 헤더 파일의 대소 문자를 구분하는 문제를 해결했다 : 캐리지 리턴을 수정하고 포함을 소문자로 수정한다. 주석 처리 된 부분이 포함을 수정합니다.

#!/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, "."); 
+0

아니요, SCM 도구를 변경하지 않을 것입니다.나는 svn 클라이언트로 사용되는 git-svn에 대해 이야기하고 있었다. 스크립트를 주셔서 감사합니다. 스크립트에 통합하겠습니다. – dimba

+0

svn : eol-style 속성을 사용하면 캐리지 리턴을 처리하는 더 좋은 방법 일 수 있습니다. –

1

다른 말처럼 원래의 문제는 SCM과는 아무런 관련이 없습니다. git 사용에 관해서는 git-svn에서 병합을 수행하고 SVN repo로 다시 푸시 할 수 있습니다. - 이것이 일회성 옵션이라는 것을 미리 알고 있어야합니다. 즉, SVN이이 커밋을 인식하지 못하게합니다. 병합되었거나 심지어 파일의 이름이 바뀌 었습니다. 이 실제로는이 아닌 한 파일 기록이 손실됩니다.

"정말로 신중한"옵션과 함께 부수적으로, 올바른 "파일 이름 바꾸기"정보를 svn으로 푸시하여 신뢰성있게 작동하는 유일한 방법은 변경하지 않고 git-svn의 파일 이름을 변경하는 것입니다. any 내용을 커밋 한 다음 원하는 파일을 수정하고 다른 커밋을 수행하십시오. 이름을 변경 한 파일을 커밋하기 전에 수정하면 git-svn은 파일에 가능성이 있음을 알고이 이동되었지만이 정보를 svn으로 푸시 할만큼 자체 발견 적 방법을 신뢰하지 않는 것 같습니다. 이 작업을 더 좋게 만드는 몇 가지 마법적인 옵션을 놓친 것 같습니다.