문제

분기의 전복 개념은 개발을 수행할 전체 저장소의 불안정한 포크를 만드는 데 초점을 맞춘 것으로 보입니다.개별 파일의 분기를 생성하는 메커니즘이 있습니까?

사용 사례의 경우 여러 플랫폼별 소스(*.c) 구현이 있는 공통 헤더(*.h) 파일을 생각해 보세요.이 유형의 분기는 영구적입니다.이러한 모든 지점은 간헐적인 지점 간 병합을 통해 지속적인 개발을 볼 수 있습니다.이는 일반적으로 수명이 유한한 불안정한 개발/안정적인 릴리스 분기와는 뚜렷한 대조를 이룹니다.

하지 마라 트렁크와 모든 분기를 지속적으로 병합하려면 불합리한 양의 유지 관리가 필요하므로 전체 저장소(저렴하든 아니든)를 분기하려고 합니다.현재 저는 이 작업을 쉽게 해주는 다른 분기 개념을 가진 ClearCase를 사용하고 있습니다.SVN으로의 전환을 고려해 달라는 요청을 받았지만 이 패러다임의 차이는 중요합니다.나는 안정 릴리스 브랜치를 잘라내는 것보다 개별 파일에 대한 대체 버전을 쉽게 만들 수 있다는 점에 훨씬 더 관심이 있습니다.

도움이 되었습니까?

해결책

안타깝게도 여기서의 실제 대답은 ClearCase가 Subversion보다 이 상황을 훨씬 더 잘 처리한다는 것입니다.Subversion을 사용하면 분기해야 합니다. 모든 것, 그러나 ClearCase는 특정 파일 그룹만 분기되고 나머지 파일은 여전히 ​​트렁크(또는 사용자가 지정한 분기)를 따른다는 것을 의미하는 일종의 "지연 분기" 아이디어를 허용합니다.

여기에 제공된 다른 솔루션은 실제로 의도한 대로 작동하지 않으며 단지 파일을 다른 경로에 복사하는 것뿐입니다.이제 실제로 해당 파일을 사용하려면 이상한 작업을 수행해야 합니다.

음, 미안해요.별로 좋은 답변은 아니었습니다.그러나 Subversion에는 이에 대한 좋은 해결책이 없습니다.그 모델은 분기 및 병합입니다.

편집하다:좋아요, crashmstr이 말한 내용을 확장해 보겠습니다.당신은 이것을 할 수 있습니다 :

svn cp $REP/trunk/file.h $REP/branched_files/file.h
svn co $REP/trunk
svn switch $REP/branched_files/file.h file.h

하지만 와!, 오류가 발생하기 쉽습니다.svn st를 수행할 때마다 다음이 표시됩니다.

svn st
    S  file.h

좀 시끄러워요.그리고 대규모 소스 저장소 내에서 몇 개의 파일이나 모듈을 분기하려고 하면 매우 지저분해지기 시작합니다.

실제로 여기에는 svn 속성을 사용하여 ClearCase의 분기 파일과 같은 것을 시뮬레이션하고 전환하고 모든 혼란을 처리하기 위해 습지 표준 svn 클라이언트 주위에 래퍼를 작성하기 위한 괜찮은 프로젝트가 있을 수 있습니다.

다른 팁

전체 저장소를 분기할 필요는 없습니다.프로젝트에 폴더 분기(예: 포함 폴더)를 만들 수 있습니다.다른 사람들이 언급했듯이 단일 파일만 "복사"할 수도 있습니다.파일이나 폴더의 복사본이 있으면 분기된 파일이나 폴더로 "전환"하여 분기 버전에서 작업합니다.

저장소에 별도의 분기 폴더를 생성하는 경우 서버 측 명령을 통해 분기 파일을 복사할 수 있습니다.

svn copy svn://server/project/header.h svn://server/branched_files/header.h

그런 다음 해당 파일을 전환하여 branches_files 저장소 경로

귀하의 문제를 이해하는 방법은 다음과 같습니다.다음 트리가 있습니다.

time.h
time.c

여러 아키텍처에 대해서는 이를 거부해야 합니다.

time.h is comon
time.c (for x386), time.c (for ia64), time.c (for alpha),...

또한 현재 VCS에서는 필요에 따라 time.c에서 많은 브랜치를 생성하여 이 작업을 수행할 수 있으며 VCS에서 파일을 체크아웃할 때 공통 트렁크의 최신 time.h와 브랜치의 최신 time.c를 자동으로 확인합니다. 당신은 노력하고 있습니다.

우려되는 문제는 브랜치를 체크아웃할 때 SVN을 사용하는 경우 트렁크에서 time.h를 매우 자주 병합해야 하거나 트렁크에 비해 오래된 파일에서 작업할 위험이 있어 허용되지 않는 오버헤드가 있다는 것입니다. 당신에게.

소스 코드의 구조에 따라 해결책이 있을 수 있습니다.당신이 가지고 있다고 상상해보십시오

 
/
/headers/
/headers/test.h
/source/
/source/test.c

그런 다음 /를 분기하고 다음을 사용할 수 있습니다. svn:외부 헤더를 트렁크 헤드에 연결하는 기능입니다.이는 디렉토리에서만 작동하며 test.h에 다시 커밋하는 것과 관련하여 몇 가지 제한 사항이 있지만(작동하려면 헤더 디렉토리로 이동해야 함) 작동할 수 있습니다.

Subversion "브랜치"는 저장소에 있는 항목의 복사본일 뿐입니다.따라서 파일을 분기하려면 다음을 수행하면 됩니다.

svn copy myfile.c myfile_branch.c

단일 파일을 분기하는 데 별 의미가 없다고 생각합니까?트렁크코드로 테스트할 수 있는 방법은 없나요?

변경 사항을 취소하고 나중에 적용하려면 대신 패치를 적용할 수 있습니다.

이 기능이 정말 필요한가요? 귀하의 VCS에서 ?

C 전처리기와 #ifdef를 사용하여 필요하지 않은 코드를 없애는 것은 어떨까요?또는 유사한 도구.

다음과 같은 것:

// foo.h:
void Foo();

// foo_win32.c
#ifdef _WIN32
void Foo()
{
   ...
}
#endif

// foo_linux.c
#ifdef _GNUC
void Foo()
{
   ...
}
#endif

때로는 그것이 딱 맞지 않으면 올바른 해결책이 아닙니다.

SVN의 브랜치는 단지 복사본일 뿐입니다.나는 당신이 원하는 방식으로 이를 수행하려면 파일의 각 버전을 저장소의 별도 디렉토리에 두고 소스 폴더로 체크아웃해야 한다고 믿습니다.즉.해당 파일을 별도의 프로젝트처럼 취급하십시오.

Subversion의 브랜치가 바로 당신이 말하는 것입니다.변경한 파일을 제외하고 모든 파일은 트렁크의 정확한 복사본입니다.이것이 SVN Book에서 언급된 "저렴한 복사" 방법론입니다.유일한 주의 사항은 변경 사항이 브랜치에 반영되도록 하기 위해 때때로 트렁크를 브랜치에 병합해야 한다는 것입니다.물론 이러한 변경을 원하지 않는 경우에는 트렁크->분기 병합이 필요하지 않습니다.

트렁크 변경 사항이 자동으로 병합되도록 허용하는 쉬운 방법 중 하나(Clear Case 패러다임 시뮬레이션)는 커밋 전 후크 스크립트를 사용하여 커밋 전에 트렁크 변경 사항을 병합하는 것입니다.(사실 이는 항상 코드 드리프트를 방지하는 좋은 전략).

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top